APNs のサーバ証明書の更新 (2021-03-29 実施)

Apple は 2021 年 3 月 29 日以降、APNs HTTP/2 endpoint で使用する証明書を既存の GeoTrust Global CA ルート証明書から Sectigo のルート証明書に移行します。
BoltzEngine を動作させている環境にて 2021 年 3 月 29 日までに GeoTrust Global CA ルート証明書と Sectigo AAA Certificate Services ルート証明書が同時にセットアップされている状態にしていただければ、期日を迎えても問題ございません。

お客様は BoltzEngine を Linux サーバーなどで運用されていらっしゃると思います。
通常は適切に動作環境を更新されていらっしゃると、これらのルート証明書は既に動作環境に導入されていらっしゃる可能性が極めて高いです。

導入されていない場合は、手動でこれらの証明書を環境に導入しておく必要があります。

Linux 環境でルート証明書の存在を確認する

各ルート証明書を入手する

Ubuntu / Debian 系 OS で確認する

deb 系の OS ではシステムで管理している証明書が /etc/ssl/certs/ に格納されています。
該当ディレクトリ内で取得した GeoTrust Global CA ルート証明書や Sectigo AAA Certificate Services ルート証明書と同一のものがないか確認をして下さい。

md5 を取って比較したり、openssl にて証明書の内容を確認して同一のものが確認できれば、既にシステムに導入済みであると考えて良いでしょう。

確認できなかった場合

確認できなかった場合は、先ず OS の更新などを先に行ってください。
それでも証明書が追加されない場合は、手動で証明書を導入してください。

deb 系の OS では手動で証明書を導入する場合は /usr/local/share/ca-certificates/ 配下に設置することになります。
直下に設置しても構わないのですが、好みで何らかのディレクトリを切っても良いと思います。

以下は実行例です。
実際の環境や状態に合わせてコマンドは読み替えてください。

$ sudo mkdir /usr/local/share/ca-certificates/extra
$ sudo cp ~/AAACertificateServices.crt /usr/local/share/ca-certificates/extra/
$ sudo update-ca-certificates

RHEL / CentOS / Amazon Linux (1, 2) 系 OS で確認する

rhel 系の OS ではシステムで管理している証明書が /etc/pki/ca-trust/source/anchors/ に格納されています。該当ディレクトリ内で取得した GeoTrust Global CA ルート証明書や Sectigo AAA Certificate Services ルート証明書と同一のものがないか確認をして下さい。

md5 を取って比較したり、openssl にて証明書の内容を確認して同一のものが確認できれば、既にシステムに導入済みであると考えて良いでしょう。

確認できなかった場合

確認できなかった場合は、先ず OS の更新などを先に行ってください。
それでも証明書が追加されない場合は、手動で証明書を導入してください。

EL6 系では update-ca-trust を導入し update-ca-trust enable で機能を有効化しておく必要がある場合があります。

rhel 系の OS では手動で証明書を導入する場合は /usr/share/pki/ca-trust-source/anchors/ 配下に設置することになります。

以下は実行例です。
実際の環境や状態に合わせてコマンドは読み替えてください。

$ sudo cp ~/AAACertificateServices.crt /usr/share/pki/ca-trust-source/anchors/
$ sudo update-ca-trust

証明書が機能しているかを確認する（2021-03-03 追記）

2021-03-03 現在、Apple は新しい証明書を適応した APNs 検証環境を提供しておりません。
その為、x day 以降本当に新しい証明書で動作するのかを実際に Push 通知を介して検証する方法が存在しません。
この問題は我々だけではなく、世界中のエンジニアも同様の問題を抱えております。

以下の手順は、期日までに実際に新証明書で APNs を検証することは出来ないものの、BoltzEngine の動作環境から新しいルート証明書を利用できるのかを確認する代替手段となっております。
あくまで安心材料を増やすための手順となり、x day 到達時の動作を完全に保証するものではございません。

openssl を用いた証明書チェーンの検証

以下の URL にて、x day 以降使用される Sectigo のルート証明書を用いた Web 環境が Apple より公開されています。

Apple PKI TLS Certificate Validation Page
https://valid-aaa-rsa.apple.com

openssl を用いてシステムの証明書を用いた検証と、Apple が担保している Sectigo AAA Certificate Services ルート証明書を直接用いた検証、ダミーの証明書を用いた対象検証を行うことで、安心材料を増やします。

間接的な検証手順

検証したいシステムにて openssl が利用できるようにする
もし検証したい環境に openssl がインストールされていない場合は、導入をご検討ください。
openssl で以下のように確認する
```
$ openssl s_client -connect valid-aaa-rsa.apple.com:443 -showcerts < /dev/null
CONNECTED(00000003)
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
verify return:1
depth=1 CN = Apple Public Server RSA CA 12 - G1, O = Apple Inc., ST = California, C = US
verify return:1
depth=0 CN = valid-aaa-rsa.apple.com, OU = management:idms.group.724911, O = Apple Inc., ST = California, C = US
verify return:1
---
　：
　：
```
結果は一部省略されています。
上記コマンドで該当 URL にアクセスした場合の証明書チェーンをルート証明書まで解決します。

depth が証明書チェーンの深度を示しており、上記の例では depth=2 にルート証明書が表示され O = Comodo CA Limited, CN = AAA Certificate Services と表示されていることがから、 Sectigo の該当のルート証明書が読み込めているのではないかと判断されます。

Sectigo が Comodo と表示されているのは、2018 年に Comodo CAが社名を変更し、新ブランドとして Sectigo を用意しているためです。
配布されていたルート証明書を使用して以下のように証明書チェーンを解決し、結果を比較する
ここでは AAACertificateServices.crt を読み込んで使用する
```
$ openssl s_client -CAfile ./AAACertificateServices.crt -connect valid-aaa-rsa.apple.com:443 < /dev/null
CONNECTED(00000003)
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
verify return:1
depth=1 CN = Apple Public Server RSA CA 12 - G1, O = Apple Inc., ST = California, C = US
verify return:1
depth=0 CN = valid-aaa-rsa.apple.com, OU = management:idms.group.724911, O = Apple Inc., ST = California, C = US
verify return:1
---
　：
　：
```
結果は一部省略されています。
AAACertificateServices.crt は検証時に検証環境に転送してご確認ください。

該当の証明書は x day 以降使用されるルート証明書であることがApple の公開ドキュメントにより担保されています。
その為、システム側の証明書が同様の結果を返しているのであれば、システムは同等の内容を含むルート証明書を適切に読み込んでいると解釈できます。
適当な不適切な証明書ファイルを使用して以下のように対象検証を行う
```
$ openssl s_client -CAfile ./dummy.crt -connect valid-aaa-rsa.apple.com:443 < /dev/null
CONNECTED(00000003)
depth=1 CN = Apple Public Server RSA CA 12 - G1, O = Apple Inc., ST = California, C = US
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = valid-aaa-rsa.apple.com, OU = management:idms.group.724911, O = Apple Inc., ST = California, C = US
verify return:1
---
　：
　：
```
結果は一部省略されています。

こちらの例ではルート証明書まで解決できておらず、 unable to get local issuer certificate と証明書エラーが返ってきています。
よって、適用な証明書ファイルでは Sectigo のルート証明書まで解決することが出来ないので、該当のコマンドで適当なルート証明書では証明書チェーンを解決できないことが確認できます。

これらの結果より上記のシステムの証明書と Apple が提示した証明書それぞれの結果がもっともらしいと解釈が可能です。
しかしながら、あくまで解釈が可能であり、安心材料を増やしているだけである点についてはご注意ください。

新しいルート証明書が適応された APNs にて動作確認ができるのは、2021 年 3 月 29 日以降となりますことをご了承下さい。

目次

APNs のサーバ証明書の更新 (2021-03-29 実施)

Linux 環境でルート証明書の存在を確認する

各ルート証明書を入手する

Ubuntu / Debian 系 OS で確認する

確認できなかった場合

RHEL / CentOS / Amazon Linux (1, 2) 系 OS で確認する

確認できなかった場合

証明書が機能しているかを確認する（2021-03-03 追記）

openssl を用いた証明書チェーンの検証

間接的な検証手順

ご不明な点はありませんか？