Certificate Manager＠AWSリソース¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. Certificate Managerとは¶
記入中...
02. セットアップ¶
ドメイン名¶
認証をリクエストするドメイン名を設定する。
検証の方法¶
DNS検証かEメール検証かを設定する。
03. 認証局¶
AWS認証局とは¶
認証局であるATSによって認証済みのSSL証明書を管理できる。
| サーバー提供者 | 名前 |
|---|---|
| 中間認証局 | ATS：Amazon Trust Services |
| ルート認証局 | Starfield社 |
04. SSL証明書の検証方法¶
ドメイン検証¶
▼ ドメイン検証とは¶
ドメインのSSL証明書を発行するためには、そのドメインの所有者であることを証明する必要がある。
ドメインを購入できるサービス (例：AWS、GCP、GMO) に検証方法が用意されている。
▼ 検証方法の変更¶
既存のSSL証明書の検証方法は変更できない。
そのため、検証方法を変更した証明書を新しく発行し、これを紐付ける必要がある。
古い証明書は削除しておく。
DNS検証¶
CMによってRoute53に自動作成されるCNAMEレコード値を使用して、ドメインの所有者であることを証明する。
証明書が失効しそうになった時に、CNAMEレコード値が照合され、CMが証明書を再発行してくれる。
注意点として、ドメインをAWS以外 (例：お名前ドットコム) で購入している場合は、NSレコード値を購入先のサービスのドメインレジストラに手作業で登録する必要があることに注意する。
Eメール検証¶
ドメインの所有者にメールを送信し、これを承認することにより所有者であることを証明する。
ドメインをAWS以外 (例：お名前ドットコム) で購入している場合は、そちらで設定したメールアドレス宛に確認メールを送信する。
05. SSL証明書¶
セキュリティポリシー¶
許可するプロトコルを定義したルールこと。
SSL/TLSプロトコルを許可しており、対応できるバージョンが異なるため、ブラウザがそのバージョンのSSL/TLSプロトコルを使用できるかを認識しておく必要がある。
| バージョン | Policy-2016-08 | Policy-TLS-1-1 | Policy-TLS-1-2 |
|---|---|---|---|
| Protocol-TLSv1 | ⭕️ | ✕ | ✕ |
| Protocol-TLSv1.1 | ⭕️ | ⭕️ | ✕ |
| Protocol-TLSv1.2 | ⭕️ | ⭕️ | ⭕️ |
SSL証明書の種類¶
DNS検証またはEメール検証によって、ドメインの所有者であることが証明されると、発行される。
SSL証明書は、PKIによる公開鍵検証に使用される。
| 証明書の種類 | 説明 |
|---|---|
| ワイルドカード証明書 | 証明するドメイン名にワイルドカードを使用したもの。 |
SSL証明書の変更¶
▼ SSL証明書の確認¶
Chromeを例に挙げると、SSL証明書はURLの鍵マークから確認できる。
＊例＊
CircleCIのサイトは、SSL証明書のためにACMを使用している。
▼ ダウンタイム¶
ALBではSSL証明書の変更でダウンタイムは発生しない。
既存のセッションを維持しつつ、新しいSSL証明書が適用される。
CloudFrontは謎...
05-02. SSL証明書の配置場所パターン¶
EC2/ECS/EKSの前段¶
▼ SSL終端¶
HTTPSによるSSLプロトコルを受け付けるネットワークの最終地点のことを、SSL終端という。
SSL証明書の配置場所は、SSL終端をどこにするかで決める。
AWSの使用上、ACMのSSL証明書を配置できないAWSリソースに対しては、外部のSSL証明書を手に入れて配置する。
トレードオフとして、パケットペイロードの暗号化処理は通信速度が低下させる。
そのため、パブリックネットワークと信頼できるネットワーク (例：データセンター、プライベートネットワーク、など) の境界をSSL終端とすることが多い。
▼ Route53 ➡︎ ALB、NLB、の場合¶
ALBでSSL終端とする場合、EC2/ECS/EKSにSSL証明書は不要である。
EC2/ECS/EKSでSSL終端とする場合、EC2/ECS/EKSにAWS以外で作成したSSL証明書を配置する。
| パターン (Route53には必ず配置) |
SSL終端 (HTTPSの最終地点) |
|---|---|
| Route53 ➡︎ ALB (ACMのSSL証明書) ➡︎ EC2/ECS/EKS | ALB |
| Route53 ➡︎ ALB (ACMのSSL証明書) ➡︎ EC2/ECS/EKS (AWS以外のSSL証明書) | EC2/ECS/EKS |
| Route53 ➡︎ ALB (ACMのSSL証明書) ➡︎ Lightsail (AWS以外のSSL証明書) | Lightsail |
| Route53 ➡︎ NLB (ACMのSSL証明書) ➡︎ EC2/ECS/EKS (AWS以外のSSL証明書) | EC2/ECS/EKS |
▼ Route53 ➡︎ LB コントローラー由来) の場合¶
AWSリソースにはACMのSSL証明書を紐づけられるが、KubernetesリソースにはAWS以外のSSL証明書 (Let’s Encrypt、CertManager、Istio) しか紐づけられない。
| パターン (Route53には必ず配置) |
SSL終端 (HTTPSの最終地点) |
|---|---|
| Route53 ➡︎ LBコントローラー (ACMのSSL証明書) ➡︎︎ Service / Pod | ALB |
| Route53 ➡︎ LBコントローラー (ACMのSSL証明書) ➡︎ Service / Pod | Ingressコントローラー |
| Route53 ➡︎ LBコントローラー (ACMのSSL証明書) ➡︎ Service / Pod (AWS以外のSSL証明書) | Pod |
▼ Route53 ➡︎ CloudFrontの場合¶
CloudFrontからALBにHTTPSリクエストを送信する場合、それぞれにSSL証明書を配置する必要がある。
ただ、CloudForntはバージニア北部で、またALBは東京リージョンで証明書を作成する必要がある。
CloudFrontに送信されたHTTPSリクエストをALBにルーティングするために、両方に紐付ける証明書で承認するドメインは、一致させる必要がある。
| パターン (Route53には必ず配置) |
SSL終端 (HTTPSの最終地点) |
|---|---|
| Route53 ➡︎ CloudFront (ACMのSSL証明書) ➡︎ ALB(ACMのSSL証明書) ➡︎ EC2/ECS/EKS | ALB |
| Route53 ➡︎ CloudFront (ACMのSSL証明書) ➡︎ EC2/ECS/EKS | CloudFront |
| Route53 ➡︎ CloudFront (ACMのSSL証明書) ➡︎ S3 | CloudFront |
▼ Route53 ➡︎ EC2/ECS/EKS、Lightsail、の場合¶
Route53でSSL終端とする場合、EC2/ECS/EKSにSSL証明書は不要である。
EC2/ECS/EKSでSSL終端とする場合、EC2/ECS/EKSにAWS以外で作成したSSL証明書を配置する。
| パターン (Route53には必ず配置) |
SSL終端 (HTTPSの最終地点) |
|---|---|
| Route53 ➡︎ EC2/ECS/EKS (AWS以外のSSL証明書) | EC2/ECS/EKS |
| Route53 ➡︎ Lightsail (ACMのSSL証明書) | Lightsail |
| Route53 ➡︎ Lightsail (ACMのSSL証明書) | Lightsail |
EC2/ECS/EKSの後段¶
▼ Aurora¶
Aurora RDSにSSL証明書を紐づける。
EC2/ECS/EKSからAurora RDSへのパケットペイロードを暗号化できる。