画像転用元[https://letsencrypt.org/ja/]
悪用厳禁です
この記事で紹介するのはLet's EncryptのSSL証明書を使って、一般的なブラウザからアクセス可能にするための手順を示します。
決して悪用しないでください。
Let's Encryptにハマった。。。
弊社のKubernetesにcert-managerを使って、ステージング環境のSSLを構築してありそこにIstioを導入したのがそもそもの始まり
「このサイトの通りやってある」と渡されたのがこのページ＝＞ https://docs.microsoft.com/en-us/azure/aks/ingress-tls#verify-a-certificate-object-has-been-created
しかし、cert-managerにIstioの設定が絡むとどうしてもClusterIssuerからの要求がcert-manager-webhookに届かない様でIstioを外すために一旦cert-managerを削除
このサイトと
https://cert-manager.io/docs/installation/kubernetes/
このClusterIssuerのACME設定
https://cert-manager.io/docs/configuration/acme/
でさくっと再構築しました。
しかし、なぜかブラウザからアクセスできず。。。
curlでは --insecure を付けないと上手く接続できない事から証明書がよろしくない事が判明
何が起きたのか
こちらのLet's Encrypt公式ガイドによりますと
まさにこれに引っかかっていました。
ChromeはそもそもこのFakeルート証明書を見せてくれず、悩みまくっていました。Safariでは「証明書のFakeルート局なんて信頼してないからダメ」って教えてくれたから理解できたけど、Chrome中途半端に開いてくれたもんでなかなか気づけなかった。。。
なぜこのバグを埋め込んだのか
参考にしたサイト間で推奨してくれた認証局が違ったみたい
そもそもLet's Encryptには２つの証明書種別があり
- ステージング用
- 本番用
でACME / server に設定するべきURLが異なります
Microsoftのcert-manager導入手順では本番用を
cert-managerの導入手順ではステージング用を
設定する様になっていたのに気づかなかったのでした 
対処
ACMEのserverにLet's Encryptの本番用URLを設定する事で回避できます。
- 本番用URL
https://acme-v02.api.letsencrypt.org/directory
反対にブラウザやその他のツールではNGとされる状態を作りたい場合はステージング用のURLを設定するとたぶん再現できます
- ステージング用URL
https://acme-staging-v02.api.letsencrypt.org/directory
おわり
SSLやネットワークが絡むトラブルシューティングは構成が複雑になりがちなのでとってもむずっこいです。。。