Certimate（certimate-go/certimate・GitHubスター9,222・MIT）は、SSL証明書の発行から配置・更新・監視までをGUIのワークフローで束ねるセルフホストOSSです。なぜ今この種の道具が要るのかというと、CA/Browser Forum の Baseline Requirements が2026年3月15日から、サーバ証明書の最長有効期間を398日から200日へ短縮したからです。2029年3月にはこれが47日になります。年1回だった更新作業が、年8回になるということです。
日本語の解説記事は執筆時点で見当たらず（Qiita検索0件、Google日本語SERPの上位も英語・中国語のみ）、READMEの数字を実際に動かして確かめたものも見つかりませんでした。この記事では公式配布バイナリ v0.4.32 を手元で起動し、公称値との差まで含めて整理します。
env -i）で起動 → HTTP 200 → RSS 計測まで。すべて本記事のために実行した実測です30秒でわかる Certimate
・何ができるか：ACME（Let’s Encrypt等）で証明書を取り、159種類の配置先（CDN・ロードバランサ・WAF・Kubernetes・SSH先など）へ自動で配り、期限前に更新して結果を通知する
・何を解決するか：証明書の最長有効期間が200日→100日→47日と短くなるなかで、更新そのものではなく「更新した証明書を配り直す作業」が破綻するのを防ぐ
・何を代替するか：certbot/acme.sh＋自作の配布スクリプト群、または各クラウドの証明書マネージャを跨いだ手作業
・実測でわかったこと：環境変数ゼロで起動でき依存は本当にゼロ。ただしメモリは公称「~16 MB」に対し実測33〜36 MiB、初回起動時点で既定の管理者アカウントが有効（公開前に必ず変更）
この記事のポイント
・READMEの「150+ の配置先 / 70+ のDNSプロバイダ」をソースの登録簿から数え直すと、実測は配置先159・DNS-01が73で、公称は控えめな表記だった
・「Zero Dependencies」は本当だった——env -i（環境変数ゼロ）で起動し、SQLite2ファイルを自動生成してHTTP 200を返した
・一方で公称「~16 MB」のメモリは実測33〜36 MiB。さらに初回起動時点で既定の管理者アカウントが有効で、変更用の環境変数は初回起動時にしか効かない
ノーコードからコードまでの自動化ツール全体の見取り図はAI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方にまとめてあります。Certimateはその中でも「証明書ライフサイクル」という一領域に絞って自動化する道具にあたります。
Certimateとは——証明書の発行・配置・更新を1本のワークフローに束ねるOSS
Certimateは Go 製の単一バイナリで、内部に PocketBase（SQLite）とWeb UIを同梱しています。使う側から見た構造は次の3層です。
・Credentials（資格情報）：DNSプロバイダやクラウドのAPIキーを登録しておく箱
・Workflow（ワークフロー）：「申請 → 配置 → 通知」を並べたDAG。条件分岐・遅延・try/catch を持つ
・Certificates（証明書）：発行済み証明書と有効期限の一覧
重要なのは2つ目のワークフローが本体だという点です。「証明書を取る」だけならcertbotで足ります。Certimateの価値は、取った証明書をその先にある無数の配置先へ配り直すところにあります。
実際に新規ワークフローを1本作ると、既定テンプレートとして次の形が生成されました。
この「try/catch が最初から入っている」点は、ソース側の定義とも一致します。ワークフローのノード型は13種類が定義されており（internal/domain/workflow.go）、内訳は制御系が start / end / condition / branchBlock / tryCatch / tryBlock / catchBlock / delay の8種、業務系が bizApply（申請）/ bizUpload（アップロード）/ bizMonitor（監視）/ bizDeploy（配置）/ bizNotify（通知）の5種です。「証明書を取る」より「取った後の分岐と失敗処理」に語彙が割かれているのがこのツールの設計思想を表しています。
なぜ2026年に効くのか——最長有効期間はすでに200日、2029年3月には47日
Certimateのような道具が今になって必要になった理由は、Certimate側ではなくCA/Browser Forum側にあります。一次ソースである Baseline Requirements（TLS BR v2.2.9）§6.3.2 は、次の表を掲げています。
| 証明書の発行日 | 最長有効期間 | ドメイン検証データの再利用期限 |
|---|---|---|
| 〜2026-03-15 | 398日 | 398日 |
| 2026-03-15〜2027-03-15 | 200日（現在） | 200日 |
| 2027-03-15〜2029-03-15 | 100日 | 100日 |
| 2029-03-15〜 | 47日 | 10日 |
見落とされがちなのは右端の列です。証明書の有効期間だけでなく、ドメイン検証（DCV）データの再利用期限も同時に短くなります。2029年3月以降はドメイン所有の再確認が10日ごとに必要になるため、「更新のときだけDNSレコードを手で置く」運用は成立しません。DNS-01チャレンジをAPIで自動化しておくことが前提になります。
この記事の数値の出どころ：有効期間の表は CA/Browser Forum の Baseline Requirements 本文（cabforum/servercert リポジトリの docs/BR.md・Version 2.2.9）を直接参照しています。ベンダーの解説記事ではなく規定本文の §6.3.2 と巻頭の施行日一覧の両方に同じ日程が載っていることを確認しました。
実測：公式バイナリを環境変数ゼロで起動する
READMEは「Zero Dependencies（データベースもランタイムもフレームワークも不要）」と書いています。これを額面どおり受け取ってよいのか、公式のリリース資産で確かめました。
まず配布形態です。v0.4.32 のリリースには8つのzipが並んでいます（darwin amd64/arm64、linux amd64/arm64/armv7、windows 386/amd64/arm64）。「Cross Platforms」の主張はこの8点で裏づけられます。手元のmacOS arm64版をダウンロードし、同じリリースに置かれた checksums.txt と照合しました。
# 公式リリースの取得と改ざん検知
curl -LO https://github.com/certimate-go/certimate/releases/download/v0.4.32/certimate_v0.4.32_darwin_arm64.zip
curl -LO https://github.com/certimate-go/certimate/releases/download/v0.4.32/checksums.txt
shasum -a 256 -c checksums.txt --ignore-missing
zipは34,750,767バイト、SHA-256は aad528be…9dbd で checksums.txt の記載と一致しました。展開して出てくる実行ファイルは1つだけで、サイズは122,926,354バイト（約117 MiB）です。159種の配置先と73種のDNSプロバイダのSDKをすべて静的リンクした結果であり、「依存ゼロ」の代償はこのファイルサイズに現れていると読めます。
次に、依存の有無を厳密に測るため環境変数を1つも与えずに起動しました。
# 環境変数ゼロ・設定ファイルなし・DBなしの状態から起動する
env -i ./certimate serve --dir pb_data --http 127.0.0.1:18090
結果は次のとおりです。
・起動した。HOME も PATH も無い状態で、エラーも警告も出さずに待ち受けを開始した
・初回起動時に v0.4.0 から v0.4.29 までのマイグレーションを順に実行し、データディレクトリを自動生成した
・curl でトップページを叩くと HTTP 200。ログイン画面のHTMLが返る
・生成された pb_data は data.db と auxiliary.db の2つのSQLiteファイル（＋WAL）のみ、合計512KB
「データベースもランタイムも不要」という主張は、このとおり成立していました。外部プロセスも設定ファイルも要求されません。セルフホスト基盤の起動条件を1つずつ剥がして確認する手順は、Openship徹底解説｜セルフホスト型デプロイ基盤でも同じやり方を取っています。
certimate version はバージョンを答えない：起動前に版を確かめようと ./certimate --version を実行すると、v0.4.32 の公式バイナリは certimate version (untracked) と返します。一方でWeb UIのフッタには v0.4.32 と表示されます。CLIだけで版を確認しようとすると判別できないため、版の確認はUIかダウンロードしたファイル名で行ってください。
実測：メモリ公称「~16 MB」と、初回起動で作られる既定の管理者アカウント
READMEは「Low Resource Usage: 極めて軽量で、必要なメモリは ~16 MB のみ」と書いています（中国語版READMEも「仅需 ~16 MB 内存」で同じ）。起動直後の常駐サイズを測りました。
| 計測 | 環境 | 起動直後のRSS |
|---|---|---|
| 1回目 | macOS arm64 / v0.4.32公式バイナリ | 34.0 MiB |
| 2回目 | 同上 | 36.4 MiB |
| 3回目 | 同上 | 34.5 MiB |
| 公称値 | README（環境の記載なし） | ~16 MB |
3回とも公称値の約2倍でした。ただしこれを「READMEが誤り」と断じるのは行き過ぎです。RSSはOSのメモリ会計方式に依存し、Goランタイムのヒープ返却タイミングでも動きます。公称値がLinuxコンテナ上の docker stats を指している可能性は十分にあり、その条件は手元で再現していません（この環境ではDockerデーモンが動作しておらず、コンテナ版との比較は未検証です）。実務上の結論としては、「16MBを前提にメモリを切り詰めた小さなVPSに詰め込む計画は立てないほうがよい。数十MB級を見込む」が安全です。ワークフロー実行中はさらに上振れします。
より重要なのは、メモリではなく初回起動で作られるアカウントのほうです。データディレクトリを新規に作って起動した直後、SQLiteの _superusers テーブルには既に1件のレコードが入っていました。ユーザー名は [email protected] で、公式READMEに記載された初期パスワードで実際に認証が通ります（自分の環境の localhost に対してのみ確認）。
READMEに堂々と書かれている以上これは秘密ではなく、むしろ「変更しないまま公開すると誰でも入れる」ことが公知だという意味です。UIのダッシュボードにも Change username or password というショートカットが最初から置かれていました。
変更方法は環境変数ですが、効くタイミングに強い制約があります。実際に対照実験をした結果が次の表です。
| 条件 | 環境変数 | 結果 |
|---|---|---|
既存の pb_data がある状態で再起動 |
指定あり | 管理者は [email protected] のまま変わらない |
| 空のデータディレクトリで初回起動 | 指定あり | 管理者が指定した値になり、既定の資格情報はHTTP 400で拒否される |
ソースを見ると理由は明快で、管理者コレクションが空のときだけ環境変数を読んで1件作る実装になっています（migrations/1757476801_initialize_v0.4.0.go）。つまり次のようになります。
# ① 効く：まっさらな状態からの初回起動時に指定する
CERTIMATE_ADMIN_USERNAME='[email protected]' \
CERTIMATE_ADMIN_PASSWORD='<十分に長いランダム文字列>' \
./certimate serve --dir pb_data
# ② 効かない：既に pb_data がある状態で後から足しても既定アカウントは残る
# → その場合はUIの「Change username or password」から変更する
先に動かしてから環境変数を足しても遅い：試用のつもりで一度起動し、その後に環境変数を追加して本番へ——という順番だと既定アカウントが残ります。試用に使った pb_data を捨てて作り直すか、UIから明示的に変更してください。Certimateはクラウド各社のAPIキーを集約して保管するため、管理画面を取られたときの影響範囲は証明書1枚では済みません。
なお、起動後のソケットも確認しました。LISTENしているのは指定したループバックアドレスの1本のみで、待機状態で外部への確立済み接続は観測されませんでした（短時間だけ張られる接続をこの方法で捕捉できるとは限らないため、「通信が皆無」と断定はしません）。既定で外に開かない設計であることは確認できます。
対応プロバイダを登録簿から数え直す——配置先159・DNS-01が73
READMEは「150+ の配置先」「70+ のドメインレジストラ」と書いています。この種の数字は更新が遅れて実態とずれることが多いので、ソースの登録簿（レジストリ）から数え直しました。Certimateはプロバイダごとに sp_<名前>.go を1ファイル置き、その中で MustRegister を1回呼ぶ構造なので、ファイル数と登録数が1対1で対応します。
| 種別 | ソース上の実測数 | READMEの記載 | 場所 |
|---|---|---|---|
| 配置先（deployers） | 159 | 150+ | internal/certmgmt/deployers |
| DNS-01 チャレンジ | 73 | 70+（”domain registrars”） | internal/certacme/certifiers |
| HTTP-01 チャレンジ | 4 | 記載なし | 同上（local / ssh / ftp / s3） |
| 通知チャネル | 10 | 「メール・Discord・Slack…など」 | internal/notify/notifiers |
| ACME CA | 11 | 「Let’s Encrypt等」＋and more | internal/domain/provider.go |
READMEの「150+ / 70+」は実態を下回る控えめな表記でした。ここで注意したいのは呼び方のずれです。READMEは70+を “domain registrars”（ドメインレジストラ）と書いていますが、実装されているのはDNSレコードを操作するAPIのプロバイダです。ドメインを登録した業者ではなく、権威DNSを預けている先を選ぶ、と読み替えてください。
HTTP-01が4件しかない点も設計の意図を映しています。HTTP-01は「Webルートにファイルを置く」チャレンジなので、置き方が local（同一ホスト）/ ssh / ftp / s3 の4通りに集約されるわけです。ワイルドカード証明書はHTTP-01では取得できないため、実運用では73件あるDNS-01側が主役になります。
CA側は11個の定数が定義されています。Let’s Encrypt（本番とステージング）、Actalis、DigiCert、GlobalSign Atlas、Google Trust Services、LiteSSL、Sectigo、SSL.com、ZeroSSL、そして任意のACME準拠CAを指す汎用エントリです。ステージング環境が最初から選べるのは、ワークフローを組みながら試す用途では地味に効きます。レート制限に当たらずに配置経路を検証できます。
ライセンスはMITで、LICENSEファイルの実体は22行の標準文面のみでした。追加条件や商用利用の制限は含まれていません（著作権表記が certimate-go（2025年）と Yoan.Liu（2024年）の2つ並んでいるのは、個人リポジトリから組織へ移管された経緯によるものです）。同種のセルフホスト系OSSを棚卸しするときの観点はawesome-sysadmin 解説でも整理しています。
Certimateとcertbot・acme.sh・legoの違いと使い分け
「証明書を自動化する」と言ったときに候補に挙がる道具は、担当する範囲が大きく違います。
| Certimate | certbot | acme.sh | lego | |
|---|---|---|---|---|
| 形態 | 常駐サーバ＋Web UI | CLI（cron/systemd） | シェルスクリプト | CLI／Goライブラリ |
| 証明書の取得 | ○ | ○ | ○ | ○ |
| 取得後の配布先への配置 | ○（159種） | フックを自作 | フックを自作 | 自作 |
| 期限の可視化 | ○（一覧・ダッシュボード） | × | × | × |
| 失敗時の通知 | ○（10チャネル） | 自作 | 自作 | 自作 |
| 設置対象 | 管理サーバ1台に集約 | 証明書を使う各ホスト | 各ホスト | 各ホスト |
| 常駐コスト | 数十MB常駐 | 常駐なし | 常駐なし | 常駐なし |
担当範囲の違いを図にすると次のようになります。上半分（証明書を取るまで）はどのツールでもできることで、分かれるのは下半分です。
DNS-01 / HTTP-01"] --> B["ACME で証明書を取得"] B --> C{"取得した証明書を
どこへ置くか"} C -->|"同じホストの
ファイルに置く"| D["certbot / acme.sh
の担当はここまで"] C -->|"CDN・WAF・LB・
K8s など多数へ配る"| E["Certimate の
配置ノード（159種）"] E --> F["期限を監視して
手前で再実行"] F -->|"失敗"| G["通知ノード（10種）"] F -->|"成功"| H["証明書一覧を更新"]
判断の軸は「証明書を使う場所がいくつあるか」です。
・1〜2台のWebサーバで完結しているなら certbot / acme.sh のほうが適切です。常駐プロセスが増えず、証明書はその場に置かれるだけで済みます
・CDN・WAF・ロードバランサ・Kubernetes・複数クラウドに証明書が散っているなら、Certimateが担当するのはまさにその配布部分です。certbotのフックスクリプトを配布先の数だけ自作・保守するコストと比べることになります
・プログラムに組み込みたいなら lego（Certimateも内部でACMEの処理にlegoを利用しています）を直接使うほうが素直です
Certimateは各ホストに入れるものではなく、管理サーバ1台に置いて全社の証明書を集中管理するタイプの道具だと捉えると位置づけが定まります。当然その1台は、全クラウドのAPIキーを持つ最重要ホストになります。ログや監視をどこに集約するかという設計判断は、LogBull解説｜セルフホスト型ログ収集で扱った論点とも重なります。
導入判断：向いているケースと、日本語UIが無いことをどう扱うか
最後に、実際に触ったうえでの向き・不向きを整理します。
向いているケース
・証明書の配布先が5か所を超え、更新のたびに「どこに配ったか」を人間が覚えている状態になっている
・国内外の複数クラウドが混在していて、各社の証明書マネージャを横断できていない
・有効期間200日化（さらに先の100日・47日）で、既存の手作業スケジュールが持たないと分かっている
・データを外部SaaSに預けたくない。セルフホストが要件になっている
向いていない・注意が必要なケース
・証明書が1〜2枚で、置き場所も1台。この規模ではcertbotのほうが運用が軽い
・日本語UIが必要：UIの言語リソースは中国語と英語の2つだけで、日本語はありません。操作者が英語UIを読める前提が要ります
・常駐プロセスを増やしたくない環境。数十MBとはいえ、24時間動くサービスが1つ増えます
・管理画面の保護を後回しにできない：既定の管理者資格情報が公知であることは、このツールを置く前に必ず潰しておく前提条件です
開発の勢いという点では安心材料が揃っています。GitHub Releases を月別に集計すると、2025年9月から2026年8月まで12か月連続で毎月2〜5本のリリースが出ており、通算100本を超えています。最新の v0.4.32 は2026年8月31日公開で、既定ブランチへのpushも同日でした。スター9,222・フォーク891という規模に対して、放置されている様子はありません。
日本語の情報がまだほとんど無いのは参入障壁ですが、裏を返せばドキュメントは英語版が整備されており（docs.certimate.me）、UIも英語で完結するということでもあります。証明書の有効期間短縮は待ってくれないので、配布先の数が増えている自覚があるなら、200日のうちに手を打っておく価値はあります。
参照ソース
・certimate-go/certimate — GitHub リポジトリ（README・LICENSE・internal/ 配下のプロバイダ登録簿・マイグレーション実装。本記事の件数はすべてここを数えたもの）
・certimate v0.4.32 リリース（配布バイナリ8点と checksums.txt。本記事の実測はこの資産を使用）
・Certimate 公式ドキュメント（対応プロバイダ一覧・設定手順）
・CA/Browser Forum — Baseline Requirements for TLS Server Certificates（v2.2.9 §6.3.2 の有効期間表と施行日一覧）
・CA/Browser Forum — Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods（2025年4月投票・採択。短縮日程を確定させた投票）
