IETF承認済み 自動証明書管理環境 (ACME)。SSL 証明書の受信の自動化に役立ちます。 その仕組みを説明しましょう。
/フリッカー/ /
なぜ標準が必要だったのでしょうか?
設定ごとの平均 ドメインの場合、管理者は XNUMX ～ XNUMX 時間を費やすことができます。 間違いを犯した場合は、申請が拒否されるまで待つ必要があり、その後でのみ再度提出することができます。 これらすべてにより、大規模なシステムの展開が困難になります。
ドメインの検証手順は認証局ごとに異なる場合があります。 標準化が欠如していると、セキュリティ上の問題が発生することがあります。 有名 システムのバグにより、XNUMX 人の CA が宣言されたすべてのドメインを検証したとき。 このような状況では、不正なリソースに対して SSL 証明書が発行される可能性があります。
IETF承認のACMEプロトコル（仕様 ）証明書を取得するプロセスを自動化および標準化する必要があります。 また、人的要因を排除することで、ドメイン名検証の信頼性とセキュリティが向上します。
この標準はオープンであり、誰でもその開発に貢献できます。 の の説明書が公開されています。
これはどう動かすのですか
ACME のリクエストは、JSON メッセージを使用して HTTPS 経由で交換されます。 このプロトコルを使用するには、ACME クライアントをターゲット ノードにインストールする必要があります。ACME クライアントは、初めて CA にアクセスするときに一意のキー ペアを生成します。 その後、これらはすべてのクライアントおよびサーバーのメッセージに署名するために使用されます。
最初のメッセージには、ドメインの所有者に関する連絡先情報が含まれています。 秘密鍵で署名され、公開鍵とともにサーバーに送信されます。 署名の信頼性がチェックされ、問題がなければ SSL 証明書の発行手続きが開始されます。
証明書を取得するには、クライアントはサーバーに対してドメインを所有していることを証明する必要があります。 これを行うために、所有者のみが実行できる特定のアクションを実行します。 たとえば、認証局は一意のトークンを生成し、それをサイトに配置するようにクライアントに要求できます。 次に、CA は Web または DNS クエリを発行して、このトークンからキーを抽出します。
たとえば、HTTP の場合、トークンのキーは、Web サーバーによって提供されるファイルに配置される必要があります。 DNS 検証中に、認証局は DNS レコードのテキスト ドキュメント内で一意のキーを探します。 すべてが正常であれば、サーバーはクライアントが検証されたことを確認し、CA が証明書を発行します。
/フリッカー/ /
意見
上の IETF、ACME は、複数のドメイン名を扱う必要がある管理者にとって役立ちます。 この標準は、それぞれを目的の SSL に関連付けるのに役立ちます。
専門家は、この規格の利点の中でもいくつかの点に注目しています。 。 SSL 証明書が実際の登録者にのみ発行されるようにする必要があります。 特に、一連の拡張機能は、DNS 攻撃から保護するために使用されます。 また、DoS から保護するために、標準では個々のリクエスト (メソッドの HTTP など) の実行速度が制限されています。 。 ACME 開発者自身 セキュリティを強化するには、DNS クエリにエントロピーを追加し、ネットワーク内の複数のポイントからクエリを実行します。
同様のソリューション
プロトコルは証明書の取得にも使用されます。 и .
最初のものは Cisco Systems によって開発されました。 その目標は、X.509 デジタル証明書の発行手順を簡素化し、可能な限りスケーラブルにすることでした。 SCEP が登場する前は、このプロセスにはシステム管理者の積極的な参加が必要であり、十分に拡張できませんでした。 現在、このプロトコルは最も一般的なプロトコルの XNUMX つです。
EST に関しては、PKI クライアントが安全なチャネル経由で証明書を取得できるようになります。 メッセージングと SSL の発行に TLS を使用し、CSR を送信者にバインドします。 さらに、EST は楕円暗号化方式をサポートしており、追加の保護層を作成します。
上の 、ACMEのようなソリューションはより広く採用される必要があります。 簡素化された安全な SSL セットアップ モデルを提供し、プロセスも高速化します。
当社の企業ブログからの追加投稿:
出所： habr.com