🥇SSL発行の自動化に向けて

多くの場合、SSL 証明書を扱わなければなりません。証明書を作成してインストールするプロセス（一般的な、ほとんどの人向け）を思い出してみましょう。

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

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

あらかじめ明確にしておきますが、弊社の主な専門分野は .net であり、それに応じて IIS やその他の Windows 関連のものになります。したがって、ACME クライアントとそのすべてのアクションも、Windows の使用の観点から説明されます。

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

著者が代表を務めるK社。 URL（例）：company.tld

プロジェクト X は私たちのプロジェクトの 1 つですが、その作業中に、証明書を扱う際には最大限の時間節約に向けて取り組む必要があるという結論に達しました。このプロジェクトには、開発、テスト、ステージング、本番の 4 つの環境があります。開発とテストは当社側で行われ、ステージングと本番環境はクライアント側で行われます。

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

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

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

プロジェクトX.dev.company.tld
プロジェクトX.テスト.会社.tld
ステージング.プロジェクトX.tld
プロジェクトX.tld

モジュール1.プロジェクトX.開発.会社.tld
モジュール1.プロジェクトX.テスト.会社.tld
モジュール1.ステージング.プロジェクトX.tld
モジュール1.プロジェクトX.tld

モジュール2.プロジェクトX.開発.会社.tld
モジュール2.プロジェクトX.テスト.会社.tld
モジュール2.ステージング.プロジェクトX.tld
モジュール2.プロジェクトX.tld

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

モジュールN.プロジェクトX.開発会社.tld
モジュールN.プロジェクトX.テスト.会社.tld
モジュールN.ステージング.プロジェクトX.tld
モジュールN.プロジェクトX.tld

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

これは、ある企業の 1 つのプロジェクトの一例にすぎません。そして、当然のことながら、プロジェクトは 1 つだけではありません。

この問題に対処する私たち全員に共通する理由は次のようになります。

比較的最近 Google、SSL証明書の最大有効期間の短縮を提案。あらゆる結果を伴う。
プロジェクトおよび会社全体の内部ニーズに合わせて SSL を発行および維持するプロセスを容易にします。
証明書レコードの集中保存により、DNS を使用したドメイン検証とそれに続く自動更新の問題が部分的に解決され、クライアントの信頼の問題も解決されます。それでも、パートナー/請負業者会社のサーバーへの CNAME は、サードパーティのリソースよりも信頼性が高くなります。
さて、最後に、この場合、「持たないよりは持つ方が良い」というフレーズが完璧に当てはまります。

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

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

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

SSL発行の自動化に向けて

私たちが興味を持っているのは最後の出力、つまりワイルドカード証明書を発行するためのドメイン所有権を確認するために利用可能なオプションです。

DNSレコードを手動で作成する（自動更新はサポートされていません）
acme-dnsサーバーを使用してDNSレコードを作成する（詳細はこちら）ここで.
独自のスクリプトを使用して DNS レコードを作成します (certbot の cloudflare プラグインに似ています)。

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

ACME DNSサーバーの設定と証明書の発行

たとえば、ドメイン 2nd.pp.ua を作成し、今後使用します。

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

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 サーバードッカーコンテナですが、Go言語が利用可能な場所であればどこでも実行できます。 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 サーバーに追加する必要があるレコードを発行します (1 回限りの手順)。

[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.

SSL発行の自動化に向けて

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

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

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

SSL発行の自動化に向けて

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

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

出所： habr.com