SSL発行の自動化に向けて

多くの場合、SSL 証明書を使用する必要があります。 証明書を作成してインストールするプロセス (ほとんどの場合、一般的な場合) を思い出してください。

• プロバイダー (SSL を購入できるサイト) を探します。
• CSRを生み出す。
• プロバイダーに送信してください。
• ドメインの所有権を確認します。
• 証明書を取得します。
• 証明書を必要な形式に変換します (オプション)。 たとえば、pem から PKCS #12 へ。
• 証明書を Web サーバーにインストールします。

比較的高速で、複雑ではなく、理解しやすいです。 このオプションは、最大 XNUMX 個のプロジェクトがある場合に非常に適しています。 もっと多くの環境があり、少なくとも XNUMX つの環境がある場合はどうなるでしょうか? 古典的な開発、ステージング、運用。 この場合、このプロセスを自動化することを検討する価値があります。 この問題をもう少し深く掘り下げて、証明書の作成と維持に費やす時間をさらに最小限に抑える解決策を見つけることを提案します。 この記事には、問題の分析と繰り返しに関する小さなガイドが含まれています。

事前に予約させていただきます。当社の主な専門分野は .net であり、それに応じて IIS およびその他の Windows 関連製品も専門としています。 したがって、ACME クライアントとそのすべてのアクションについても、Windows を使用する観点から説明します。

これは誰に関係するのか、そしていくつかの初期データ

著者が代表を務めるK社。 URL (例): company.tld

プロジェクト X は私たちのプロジェクトの XNUMX つであり、これに取り組んでいるうちに、証明書を扱う際に最大限の時間を節約する必要があるという結論に達しました。 このプロジェクトには、開発、テスト、ステージング、運用の XNUMX つの環境があります。 開発とテストは私たちの側にあり、ステージングと本番はクライアント側にあります。

このプロジェクトの特別な特徴は、サブドメインとして利用できるモジュールが多数あることです。

つまり、次のような図があります。

デベロッパー
ホイール試乗
上演
生産

projectX.dev.company.tld
projectX.test.company.tld
staging.projectX.tld
プロジェクトX.tld

module1.projectX.dev.company.tld
module1.projectX.test.company.tld
module1.staging.projectX.tld
module1.projectX.tld

module2.projectX.dev.company.tld
module2.projectX.test.company.tld
module2.staging.projectX.tld
module2.projectX.tld

...
...
...
...

moduleN.projectX.dev.company.tld
moduleN.projectX.test.company.tld
moduleN.staging.projectX.tld
moduleN.projectX.tld

実稼働環境では、購入したワイルドカード証明書が使用されますが、ここで疑問は生じません。 ただし、これはサブドメインの最初のレベルのみをカバーします。 したがって、*.projectX.tld の証明書がある場合、staging.projectX.tld では機能しますが、module1.staging.projectX.tld では機能しません。 でも、なぜか別のものを買いたくないんです。

そしてこれは、ある企業の XNUMX つのプロジェクトの例に基づいているにすぎません。 そしてもちろん、プロジェクトは複数あります。

誰もがこの問題に取り組む一般的な理由は次のとおりです。

• Относительнонедавно Google、SSL証明書の最大有効期間を短縮することを提案。 すべての結果を伴います。
• プロジェクトや会社全体の内部ニーズに合わせて、SSL の発行と維持のプロセスを促進します。
• 証明書レコードの集中ストレージ。これにより、DNS を使用したドメイン検証とその後の自動更新の問題が部分的に解決され、クライアントの信頼の問題も解決されます。 それでも、パートナー/実行企業のサーバー上の CNAME は、サードパーティのリソース上の CNAME よりも信頼できます。
• さて、最後に、この場合は「持たないよりはあったほうが良い」という表現がぴったりと当てはまります。

SSLプロバイダーの選択と準備手順

無料の SSL 証明書で利用可能なオプションの中で、cloudflare と letsencrypt が検討されました。 この (および他のいくつかのプロジェクト) の DNS は Cloudflare によってホストされていますが、私はその証明書を使用するのが好きではありません。 したがって、letsencrypt を使用することにしました。
ワイルドカード SSL 証明書を作成するには、ドメインの所有権を確認する必要があります。 この手順には、DNS レコード (TXT または CNAME) を作成し、証明書を発行するときにそれを検証することが含まれます。 Linuxにはユーティリティがあります - 証明書を使用すると、このプロセスを部分的に (または一部の DNS プロバイダーでは完全に) 自動化できます。 Windowsの場合は以下から 見つけて確認した 私が決めた ACME クライアント オプション WinACME.

ドメインのレコードが作成されたので、証明書の作成に進みましょう。

最後の結論、つまり、ワイルドカード証明書を発行するためにドメインの所有権を確認するために利用できるオプションに興味があります。

1. DNS レコードを手動で作成します (自動更新はサポートされていません)
2. acme-dns サーバーを使用して DNS レコードを作成する (詳細については、こちらをご覧ください) ここで.
3. 独自のスクリプトを使用して DNS レコードを作成します (certbot 用の Cloudflare プラグインと同様)。

一見すると、2 番目の点は非常に適切ですが、DNS プロバイダーがこの機能をサポートしていない場合はどうなるでしょうか? しかし、一般的なケースが必要です。 ただし、CNAME レコードは誰もがサポートしているため、一般的なケースとなります。 したがって、ポイント XNUMX で停止し、ACME-DNS サーバーの構成に進みます。

ACME-DNS サーバーと証明書発行プロセスのセットアップ

たとえば、ドメイン 2nd.pp.ua を作成し、今後はそれを使用する予定です。

必須要件 サーバーが正しく動作するには、そのドメインの NS レコードと A レコードを作成する必要があります。 そして、私が遭遇した最初の不愉快な瞬間は、cloudflare (少なくとも無料使用モード) では、同じホストに対して NS レコードと A レコードを同時に作成できないことです。 これが問題というわけではありませんが、バインドでは可能です。 サポートは、パネルがこれを行うことを許可していないと答えました。 問題ありません。XNUMX つのレコードを作成しましょう。

acmens.2nd.pp.ua. IN A 35.237.128.147
acme.2nd.pp.ua. IN NS acmens.2nd.pp.ua.

この段階で、ホストは解決する必要があります acmens.2nd.pp.ua.

$ ping acmens.2nd.pp.ua
PING acmens.2nd.pp.ua (35.237.128.147) 56(84) bytes of data

しかし acme.2nd.pp.ua サービスを提供する DNS サーバーがまだ実行されていないため、解決されません。

レコードが作成されたので、ACME-DNS サーバーのセットアップと起動に進みます。 私のubuntuサーバー上に存在します ドッカー コンテナですが、golang が利用できる場所ならどこでも実行できます。 Windows も非常に適していますが、私はやはり Linux サーバーを好みます。

必要なディレクトリとファイルを作成します。

$ mkdir config
$ mkdir data
$ touch config/config.cfg

お気に入りのテキスト エディターで vim を使用し、サンプルを config.cfg に貼り付けてみましょう。 構成.

正常に操作するには、一般セクションと API セクションを修正するだけで十分です。

[general]
listen = "0.0.0.0:53"
protocol = "both"
domain = "acme.2nd.pp.ua"
nsname = "acmens.2nd.pp.ua" 
nsadmin = "admin.2nd.pp.ua" 
records = 
    "acme.2nd.pp.ua. A 35.237.128.147",
    "acme.2nd.pp.ua. NS acmens.2nd.pp.ua.",                                                                                                                                                                                                  ]
...
[api]
...
tls = "letsencrypt"
…

また、必要に応じて、メイン サービス ディレクトリに docker-compose ファイルを作成します。

version: '3.7'
services:
  acmedns:
    image: joohoi/acme-dns:latest
    ports:
      - "443:443"
      - "53:53"
      - "53:53/udp"
      - "80:80"
    volumes:
      - ./config:/etc/acme-dns:ro
      - ./data:/var/lib/acme-dns

準備ができて。 実行できます。

$ docker-compose up -d

この段階で、ホストは解決を開始するはずです acme.2nd.pp.ua、404 が表示されます https://acme.2nd.pp.ua

$ ping acme.2nd.pp.ua
PING acme.2nd.pp.ua (35.237.128.147) 56(84) bytes of data.

$ curl https://acme.2nd.pp.ua
404 page not found

これが表示されない場合 - docker logs -f <container_name> 幸いなことに、ログは非常に読みやすいです。

証明書の作成を開始できます。 管理者として powershell を開き、winacme を実行します。 私たちは選挙に興味があります:

• M: 新しい証明書を作成します (フルオプション)
• 2:手動入力
• 2: [dns-01] acme-dns で検証レコードを作成 (https://github.com/joohoi/acme-dns)
• ACME-DNS サーバーへのリンクについて尋ねられたら、作成したサーバーの URL (https) を回答に入力します。 acme-dns サーバーの URL: https://acme.2nd.pp.ua

最初に、クライアントは既存の DNS サーバーに追加する必要があるレコードを発行します (XNUMX 回限りの手順)。

[INFO] Creating new acme-dns registration for domain 1nd.pp.ua

Domain:              1nd.pp.ua
Record:               _acme-challenge.1nd.pp.ua
Type:                   CNAME
Content:              c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Note:                   Some DNS control panels add the final dot automatically.
                           Only one is required.

必要なレコードを作成し、それが正しく作成されたことを確認します。

$ dig CNAME _acme-challenge.1nd.pp.ua +short
c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.

winacme に必要なエントリが作成されたことを確認し、証明書の作成プロセスを続行します。

certbot をクライアントとして使用する方法について説明します ここで.

これで証明書の作成プロセスが完了し、Web サーバーにインストールして使用できるようになります。 証明書を作成するときにスケジューラでタスクも作成すると、今後は証明書の更新プロセスが自動的に実行されます。

出所： habr.com