Amazon AWSのELBとCloudFrontで使えるらしい、無料の証明書発行サービスで、AWS Certificate Manager(ACM)というのがあるそうです。([参考1])。ちょっと気になったきっかけはJavaからHTTPSで繋ぐと検証失敗するケースがあった


というので、ちょっと見始めたらドツボにはまったので、少しメモを書き残しておこうかとおもいます。

ACMの証明書を使ったサイトにブラウザで繋いでみると、、、

Javaで繋がらないとなると、ルート証明書や中間CA証明書が入ってないんだろうと疑ってみるとおもいます。 とりあえず、ブラウザで繋いだりしてみました。Windows 7のChromeやIEだとこんなパス。
view-ch-ie
Mac OS X(や多分iOSも)だとSafariでもChromeだとこんなパス。
safari-view
FirefoxだとOSによらず、WindowsでもMac OS Xでもこんなパス。
view-ff-chain
クライアント毎に使われている信頼するルート証明書が違うようです。 Starfieldルートになっているケースもありますね。 調べてみると、AmazonはGoDaddyからStarfieldルート認証局を一つ買ったのだそうです。

ACMの証明書を使ったサイトにブラウザで繋いでみると、、、

Amazonの証明書発行サービスはAmazon Trust Servicesというのだそうで、 証明書ポリシ、認証実施規程などの文書、ルート証明書、中間CA証明書などが置いてある リポジトリはこちらにあるようです。

リポジトリをよく見てみると、クロス証明書(片方向相互認証証明書、中間CA証明書)の リストがあるんですが、ハッシュと証明書のリンクが張ってあるだけで、大した説明もなく えらく不親切なページですよね。 認証局の構成がよくわからなかったので、これを元に図にしたのがコレです。(かなりの力作だとおもいます。)
ca-structure

なんかCAの鍵使いまわしてないですか?

このクロス証明書のリストで気になったのが、各Amazon Root 1〜4に対して、origとそうじゃないやつ、Starfieldに関してはv2とそうじゃないやつがある所です。 例えば、Amazon Root 1のorigとそうじゃないやつを比較してみると 以下の3点が違うだけで、

  • シリアル番号が違う
  • notBeforeが違う(origが2015年10月で、orig無しが2015年5月)
  • authorityInfoAccess拡張のcaIssuerのURLが少し違う。 http://{crl,crt}.rootg2.amazontrust.com/rootg2.cer となっている。origがcrlで、origなしがcrt。
とほとんど同じで、caIssuerを直したいだけのつまらない理由のために、中間CA証明書を再発行したようです。 これって中間CAの鍵を使いまわしてますよね。マズくないんですかね? さらに問題なのは、
  • どちらが正しい証明書なのかわからない。
  • ファイル名からはorigが古いように見えるが、 notBefore的には逆にorigが新しいようにも見える。
  • どちらか一方を失効しているわけでもなく、どちらも有効。
  • パス検証としてはどちらを使っても検証成功となるが、そんな事でいいのか?
  • 将来、{crl,crt}.rootg2.amazontrust.comのいずれかを無くす計画があると思うが、 それが明らかになっていない。
といった所です。 ちなみに、caIssuerに記載されたURLは、今の所はどちらもアクセス可能なようです。 両方にアクセスできるなら、なおさら中間CA証明書再発行の必要があったんですかねぇ? 単に、DNSの別名、CNAMEレコードの設定だけの問題なんじゃないですかねぇ。 また、本当はどちらに寄せたいと思っているのかも明らかにされてませんよねぇ。

同様に、Starfield Class 2 CAからStarfield Services Root CA G2に発行している 中間CA証明書も怪しくて、シリアル番号とnetBeforeだけが違う証明書があります。 どちらも失効していません。 こんなことして大丈夫なんですかねぇ? 最近、Certificate Transparency(CT)でSSLサーバー証明書全ての発行履歴残されており、 (私は最初はCTは嫌いだったのですが、) 認証局が問題あると、 (シマンテックのように、、、、) いろんな人が指摘してくれます。 中間CA証明書の発行についても、CTログに残しておかないと、 ヤバイ運用があるんじゃないかなぁ、、、、と思います。

Amazonの認証局はWebTrust認定もしており、Ernst Youngが監査しているそうですが、 こんなんで本当に大丈夫なんですかね?

Java 8?のcacertsのaliasについて

Amazon AWSやACMとは全く無関係ですが、最近自分は、Javaはめっきり触らなくなってしまい、今回の件でかなり苦労しました。Javaの信頼する認証局のためのキーストアファイルであるjre/lib/security/cacertsファイルなんですが、中のファイルを取り出そうとすると、そんなファイルは無いと怒られてしまいました。 よく見ると使ってみた新しい8u121では、aliasはこのようになっており、

% keytool -list -keystore jre/lib/security/cacerts   :中略 globalsigneccrootcar5 [jdk],2016/08/26, trustedCertEntry, 証明書のフィンガプリント(SHA1): 1F:24:C6:30:CD:A4:18:EF:20:69:FF:AD:4F:DD:5F:46: 3A:1B:69:AA starfieldservicesrootg2ca [jdk],2016/08/26, trustedCertEntry, 証明書のフィンガプリント(SHA1): 92:5A:8F:8D:2C:6D:04:E0:66:5F:59:6A:FF:22:D8:63: E8:25:6F:3F ttelesecglobalrootclass2ca [jdk],2016/08/26, trustedCertEntry, 証明書のフィンガプリント(SHA1): 59:0D:2D:7D:88:4F:40:2E:61:7E:A5:62:32:17:65:CF: 17:D8:94:E9 addtrustqualifiedca [jdk],2016/08/26, trustedCertEntry, 証明書のフィンガプリント(SHA1): 4D:23:78:EC:91:95:39:B5:00:7F:75:8F:03:3B:21:1E: C5:4D:8B:CF   :後略
例えば「starfieldservicesg2ca」だけではだめで、表示されている通り「starfieldservicesg2ca [JDK]」のようにちゃんと[JDK]までつけないといけなくなったのだそうです。知らなかったし、ハマりました。

GWなもんで、今日はこんなとこで。

参考リンク

A look at AWS Certificate Manager
ACMを使い始めるときに参考になる。ACMを使ったサイト。
Free SSL With Amazon’s AWS Certificate Manager (ACM)
ACMを使い始めるときに参考になる。(その2)
ACM FAQ
公式サイトのFAQ