SSL証明書の発行・更新について

この記事は弥生 Advent Calendar 2022の15日目のエントリーです。

こんにちは 弥生の情報システムのつじのです

インフラチームに所属しており、オンプレ環境からクラウド環境まで幅広い範囲を担当してます。

今回は今年私が担当したSSL証明書に関する内容を記事にしてみました。

なにかを実装したわけでもないので、あまり派手な内容でもないのですがよかったら最後までお付き合い下さい。

インフラチームで対応していること

弥生ではさまざまなオンラインサービスを展開していますが、それらのサービスに必要なのが安全でセキュアな通信です。

その実現のためインフラチームでは主に以下のようなSSL証明書の発行・更新対応を行っています。
今回は【対応その①】について記事で紹介いたします!

【対応その①】:弥生ドメイン(XXX.yayoi-kk.co.jp)を保護する証明書の発行・更新対応

【対応その②】:アプリケーションが使用しているルート証明書の更新

この発行・更新対応の範囲は弥生がデータセンター、パブリッククラウド(AWS・Azure)上にサービスを展開している都合上、それなりに大きなイベントとなっています。

SSL証明書発行

新たにドメインを保護する・既存ドメインの保護を更新する場合のどちらにしても有効なSSL証明書が必要です。

有効なSSL証明書の取得方法は色々あるのですが、大体この通りになると思います。

  1. 保護対象ドメインのCSR作成する
  2. CSR情報をもとに認証局に証明書の発行(購入)申請を行う

この2番の対応は認証局の申請手順に従えば特に問題無く対応できるのですが、1番はOpenSSLを使用し、これからどんなSSL証明書を発行するのか決めるため注意が必要です。

# 秘密鍵生成
$ openssl genrsa -aes256(DES, DES3, AES128, AES192, AES256 など)  -out 鍵ファイル.key -rand 乱数用ファイル.dat 2048(鍵長)
# CSR生成
$ openssl req -new -key 鍵ファイル.key -out CSRファイル.csr
Enter pass phrase for 鍵ファイル.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:JP
State or Province Name (full name) []:Tokyo
Locality Name (eg, city) [Default City]:Chiyoda-ku
Organization Name (eg, company) [Default Company Ltd]:Yayoi Co.,Ltd.
Organizational Unit Name (eg, section) []:IS
Common Name (eg, your name or your server's hostname) []:保護対象ドメイン(XXX.yayoi-kk.co.jpなど)
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
$

※パスフレーズや暗号強度など一部記載を変えています

更新

発行を行うとSSL証明書となる文字列が生成されます。

これは認証局により受け取り方法が異なるのですが、ブラウザ上に表示される場合やメールで受け取る形式が一般的かと思います。

ここからの対応でオンライン上にSSL証明書を反映させていきます。

弥生の場合、反映環境は以下の通り何パターンかあります。
1. オンプレLB
2. Azure上のマネージドサービス(AppServiceApplicationGatewayなど)
3. AWS上のALB

他環境にも保護対象ドメインがありSSL証明書で保護しているのですが、そこはAWSのACMなどで自動更新が行われる様になっています。

各環境のリソースへ取得したSSL証明書をアップロードし、既存の証明書が適用されている場合はアクティヴとなるように変更することで更新は完了となります。

CDNサービス以外は基本的に即時反映のため、このタイミングが一番緊張する瞬間です。。。。。

更新が終われば監視用のエンドポイントなどにhttps通信を行い、証明書が更新されている事を確認します。

確認にはcurlコマンドを使用し、発行した証明書の有効期限となっているか確認しています。

$ curl -v https://smart.yayoi-kk.co.jp/healthcheck ←確認対象ドメイン
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 23.195.88.193:443...
* Connected to smart.yayoi-kk.co.jp (23.195.88.193) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
*  CAfile: C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
*  CApath: none
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [29 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [2767 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [79 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted h2
* Server certificate:
*  subject: C=JP; ST=Tokyo; L=Chiyoda-ku; O=Yayoi Co.,Ltd.; CN=*.yayoi-kk.co.jp
*  start date: Jun 26 00:00:00 2022 GMT
*  expire date: Jun 27 23:59:59 2023 GMT ←確認対象有効期限
*  subjectAltName: host "smart.yayoi-kk.co.jp" matched cert's "*.yayoi-kk.co.jp"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS RSA SHA256 2020 CA1
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
} [5 bytes data]
=================================
省略
=================================
< HTTP/2 200
< content-length: 0
< cache-control: no-cache, no-store
< expires: -1
< pragma: no-cache
< x-frame-options: SAMEORIGIN
< x-content-type-options: nosniff
< x-ua-compatible: IE=edge
< date: Tue, 13 Dec 2022 03:19:52 GMT
=================================
省略
=================================
{ [0 bytes data]
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Connection #0 to host smart.yayoi-kk.co.jp left intact

今後の対応

ここまで弥生で行っているSSL証明書の発行や、更新対応について簡単に紹介させていただきました。

今後の対応としてはまだまだ更新対象リソースに対して個別にSSL証明書を適用している箇所があるため、AWSならACM、AzureならKey Vaultなどを使用して更新対応の効率化を進めていきたいと考えています。

あとがき

今回紹介した内容は最初に記載したインフラチームが担当している業務範囲のごく一部です。 まだまだやること・やりたいことが沢山あるチームなので一つ一つのタスクを効率化していければと思います。

また、対応していることに記載した『【対応その②】:アプリケーションが使用しているルート証明書の更新』に関しては今回記載できなかったので、またいずれ記載したいと思います。

一緒に働く仲間を募集しています

herp.careers