SSLサーバ証明書取得代行サーバを作ってみた。

上長より指令
「某SSLサーバ証明書ベンダのACME対応版を提供できるようにせよ」

サーバ証明書の有効期間がさらに短くなるっぽいという話を受けての動きではあるのですが……

おぢさん考えました。
「そんなん certbot 入れたらしまいやん」

つまらん！

ベンダの資料を眺めつつ、通常版サーバ証明書(非ACME版)でいろいろ見聞きした情報を整理します。
・WEBサイト非公開な環境ではファイル認証を受けられない
・DNS認証を受けるために公開されたDNSサーバでDNSレコード登録が必要。
・しかも更新の都度認証プロセスが必要。

改めて考えました。
「どこまでやる? やれる?」
・お客さんのサーバ運用形態に左右されない
・完全にオートマチックで
・ワイルドカード証明書にも対応したい❣
・サーバの仕込みはエンジニアでやるが、申請関連の事務レベルはWEBで

ここまで書いてると脳内でシステム構成がまとまってきます。
1.certbot運用は DNS-01 認証のみ。(HTTP-01認証でよいなら各サーバで)
2.WEBサーバ＋DNSコンテンツサーバ
3.ドメイン名を入力するだけでサーバ証明書発行までできれば
4.テスト環境や複数のベンダに対応したい

そうするとこんなマンガができあがります。

構築、構成のポイントはこういうあたり
(概要図に記載のない妄想も含む)
1.certbotで複数ベンダに対応
2.WEBでいろいろ入力してcertbot連携
3.ベンダ固有の情報はベンダ提供のコンパネで。
4.DNSコンテンツサーバに連動
5.サーバ証明書を手元で管理して顧客サーバへ配送

メリットとしては、前述とも一部重複しますが、
1.顧客サーバでACMEクライアントを運用する必要がない
　　→ web非公開やDNS運用していないサーバでも証明書を適用できる
2.利用者登録を極力少なくできる。(事務方都合で……)
　　→ 特定IDに集約して運用するため。テスト環境や別ベンダ適用と同様にお客様個別の対応も可能
3.ワイルドカード証明書の発行/更新が容易
4.DNSコンテンツサーバの挙動や設定を意識する必要がない
　　→ お客様で1件委任レコードの登録が必要ですけどー
等々

エンジニアで個別に組み込み対応が必要なのは、
1.サーバ証明書データを顧客サーバへ転送する
　　→ 定期バッチに追記できるようにした。
2.サーバ証明書データを各サービスの設定に組み込み、反映する
　　→ サンプルスクリプトを用意した。
　　　標準的なサーバであればドメイン名書き換えのみでOK
3.それらを定期実行に組み込む

実際の構成、流れはこんな感じ。
結構ごちゃごちゃしてしまうのだけれど……

一応登録画面も紹介しておきます。

certbot(に限らずACMEクライアント)運用のポイントとしては、
1.ベンダから提示されたサーバ(URL)を --serverパラメータで指定する
2.ベンダから提供された認証情報で事前に regist する
3.複数ベンダで運用する際は --config-dir で領域まるごと分けてしまうと簡単。
4.ドメイン名指定で renew しようとすると怒られるので、certonly等に置き換える
5.dns認証の場合は _acme-challenge.ドメイン名 が参照されるので certbotがレコード更新しようとするコンテンツDNSサーバが参照されるように事前に委任等の工夫をしておく

ぐらいですかねぇ。
「もっとこうしたほうがいい」とかあれば教えていただけると嬉しいです。

2025.02.12 加筆