専用ロードバランサーでの証明書の検証
SSL エンドポイントの CA 証明書を 1 つ以上指定すると、ロードバランサーは以下の HTTP ヘッダーを使用してクライアント証明書データを API に渡します。
-
X-SSL-Client-Verify
次のいずれかが返されます。
-
SUCCESSクライアントは
SUCCESS が返された場合にのみ検証されます。 -
証明書が存在しない場合は
NONE が返されます。 -
他の検証エラーが発生した場合は
FAILED が返されます。
-
-
X-SSL-Client-DN
クライアント証明書の完全な識別名が含まれます。
-
X-SSL-Issuer
発行元証明書の完全な識別名が含まれます。
-
X-SSL-Client-Serial
クライアントを識別するために CA で使用されるシリアル番号が含まれます。
| クライアント証明書は DLB レベルで検証されますが、API レベルでの再検証は行われません。TLS は DLB と API の間で一方向になります。 |
失効リストの追加
CloudHub ロードバランサーは、必要に応じて証明書失効リスト (CRL) に対してクライアント要求を検証できます。アップロードするには、暗号化されていない、PEM でエンコードされた 1 つのファイルにすべての CRL ファイルを連結する必要があります。CRL 内での項目の順序は重要ではありません。
失効リストを追加するには、ロードバランサーの作成時に cloudhub load-balancer create コマンドで --crl オプションを使用します。
ロードバランサーがすでに作成されている場合は、 CloudHub API を使用して CRL を追加または更新できます。この場合は、PATCH 要求に revocationList 要素を追加して /organizations/{myOrgID}/vpcs/{myVpcID}/loadbalancers/{myDlbID} エンドポイントに送信します。
[
{
"op": "replace",
"path": "/sslEndpoints/0/revocationList",
"value": "-----BEGIN X509 CRL-----\nMIIBTTCBtwIBATANBgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJBVTETMBEGA1UE\nCBMKU29tZS1TdGF0ZTEhMB8GA1UEChMYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRk\nMRAwDgYDVQQDEwdvcmcuY29tFw0xNjAzMTUwOTI2MThaFw0xODAzMTUwOTI2MTha\nMBwwGgIJAIBvvO4dJHjhFw0xNjAzMTUwODUwMTZaoA4wDDAKBgNVHRQEAwIBBjAN\nBgkqhkiG9w0BAQUFAAOBgQCCAbGXW+Hnzmd1bXqWsFXfogOsJScoxkJOhhmjui3I\nhTUyO5plGHUBLjBnDkypM+iLfn0W4wPcNj7FZdz4Hu/WLntxwrTtR5YOcfIhEGcq\nwvJq/1+WKUPC6eqGwx0iKOOBIWsaf5CNOOUQMo6RaeTeu8Uba2EGFk1Vu/SoZYAK\nsw==\n-----END X509 CRL-----\n"
}
]CLI から myVpcID と myDlbID の値を取得するには、それぞれ cloudhub vpc describe-json コマンドと cloudhub load-balancer describe-json コマンドを使用します。
他のプロパティを更新するには、PATCH 要求をロードバランサーエンドポイントに送信します。
証明書暗号化スイートを管理するための準備
CloudHub API で暗号化スイートを管理するためには、事前に以下を行う必要があります。
-
CloudHub API を使用して組織 ID を取得する。
「単一組織の取得」を参照してください。
-
CloudHub API を使用して VPC ID を取得する。
cloudhub vpc describe-json を参照してください。
-
CloudHub API を使用して DLB ID を取得する。
cloudhub load-balancer describe-json を参照してください。
-
jq をインストールして JSON 出力を書式化する。jq を参照してください。
認証ベアラートークンの生成
Anypoint Platform 用の認証ベアラートークンを生成する手順は次のとおりです。
-
Anypoint Platform のユーザー名とパスワードを API に送信します。
curl -X POST 'https://anypoint.mulesoft.com/accounts/login' -H 'Content-Type: application/json' -d '{"username":"myUsername","password":"myPassword"}'このコマンドによりアクセストークンが返されます。
{ "access_token": "myAccessToken", "token_type": "bearer", "redirectUrl": "/home/" } -
API コールで使用する
access_token の値をコピーします。
証明書暗号化スイートの管理
CloudHub API を使用すると、以下を行うことができます。
使用可能な暗号化スイートのリスト
CloudHub API を使用して組織で使用可能な暗号化スイートをリストする手順は、次のとおりです。
-
証明書暗号化スイートを管理するための準備をします。
-
次の GET コールを実行します。
curl https://anypoint.mulesoft.com/cloudhub/api/organizations/myOrgID/loadbalancers/ciphersuites -H 'Authorization: Bearer myAccessToken' | jq-
myOrgID が組織 ID です。 -
myAccessToken は、生成したアクセストークンです。
-
出力には ciphers が含まれます。
{
"data": [
{
"id": "5b4a36e1e65c892316abd4d1",
"name": "NewDefault-v1",
"ciphers": "ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384",
"description": "Default ciphers (new version)-v1",
"defaultSuite": true
},
{
"id": "5b4a36e1e65c892316abd4d2",
"name": "OldDefault",
"ciphers": "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4",
"description": "Default ciphers (old version)",
"defaultSuite": false
},
{
"id": "5b4bfedee4b0f45ab1de6979",
"name": "EcdheEcdsaRsa",
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384",
"description": "ECDHE ECDSA RSA ciphers",
"defaultSuite": false
},
{
"id": "5ba28106e4b00522d78f40b6",
"name": "RestrictCiphers",
"ciphers": "AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256",
"description": "Restricted Ciphers",
"defaultSuite": false
}
],
"total": 4
}推奨される暗号化スイート
次に示す推奨される暗号化スイートは、SSL エンドポイントの互換性とセキュリティのバランスが取れています。
ECDHE-RSA-AES256-GCM-SHA512 DHE-RSA-AES256-GCM-SHA512 ECDHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-GCM-SHA384
ほとんどの暗号化スイートは、前方秘匿性を提供します。RC4-SHA (Internet Explorer 8 をサポート) は前方秘匿性を提供しません。 そのため、MuleSoft と Microsoft は RC4-SHA の使用を推奨していません。
CloudHub の専用ロードバランサーでは、TLS 1.2 をサポートしています。 TLS 1.1 は無効になっており、デフォルトではサポートされていません。
TLS 1.0 を設定することもできますが、このプロトコルには重大な脆弱性があるため PCI コンプライアンスでは受け入れられません。
DLB のデフォルト暗号化スイートの表示
CloudHub API を使用して DLB のデフォルトの暗号化スイートを表示する手順は、次のとおりです。
-
証明書暗号化スイートを管理するための準備をします。
-
次の GET コールを実行します。
curl https://anypoint.mulesoft.com/cloudhub/api/organizations/myOrgID/vpcs/myVpcID/loadbalancers/myDlbID -H 'Authorization: Bearer myAccessToken' | jqコマンドでは:
-
myOrgID が組織 ID です。 -
myVpcID は VPC の ID です。 -
myDlbID は DLB の ID です。 -
myAccessToken は、生成したアクセストークンです。
-
出力には defaultCipherSuite が含まれます。
"defaultCipherSuite": "ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384"デフォルトの暗号化スイートの置換による暗号化の循環
CloudHub API を使用して DLB のデフォルトの暗号化スイートを置換することで暗号化を循環する手順は、次のとおりです。
-
証明書暗号化スイートを管理するための準備をします。
-
次の PATCH コールを実行します。
curl -X PATCH https://anypoint.mulesoft.com/cloudhub/api/organizations/myOrgID/vpcs/myVpcID/loadbalancers/ myDlbID -H 'Authorization: Bearer myAccessToken' -H 'Content-Type: application/json' -d '[{"op":"replace", "path":"/defaultCipherSuiteName", "value":"NewDefault-v1"}]' | jqコマンドでは:
-
myOrgID が組織 ID です。 -
myVpcID は VPC の ID です。 -
myDlbID は DLB の ID です。 -
myAccessToken は、生成したアクセストークンです。 -
NewDefault は、使用可能な暗号化スイートのリストで生成した使用可能な暗号化スイートのリストに含まれている暗号化スイートの name です。
-
この出力には defaultCipherSuite が含まれます。
"defaultCipherSuite": "ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384"TLS 1.0 をサポートするようにデフォルトの暗号化スイートを変更する
TLS 1.0 をサポートするには、デフォルトの暗号化スイートを OldDefault に変更します。
-
証明書暗号化スイートを管理するための準備をします。
-
デフォルトの暗号化スイートを変更します。
curl -X PATCH https://anypoint.mulesoft.com/cloudhub/api/organizations/myOrgID/vpcs/myVpcID/loadbalancers/myDlbID -H 'Authorization: Bearer myAccessToken' -H 'Content-Type: application/json' -d '[{"op":"replace", "path":"/defaultCipherSuiteName", "value":"OldDefault"}]' | jqコマンドでは:
-
myOrgID が組織 ID です。 -
myVpcID は VPC の ID です。 -
myDlbID は DLB の ID です。 -
myAccessToken は、生成したアクセストークンです。 -
OldDefault は TLS 1.0 をサポートする暗号化スイートの名前です。
-
-
デフォルトの暗号化スイートを確認して、出力に次の行が含まれることを確認します。
"defaultCipherSuite": "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"
TLS 1.0 接続の確認
TLS 1.0 を有効にしたら、接続をテストします。
-
opensslDLB SSL エンドポイントに対して次のコマンドを実行します。
openssl s_client -connect DNS of the SSL endpoint:443 -tls1-
出力に証明書情報と
Secure Renegotiation IS supported というメッセージが含まれる場合、TLS 1.0 がサポートされています。 -
コマンドで
write:errno=54 が返された場合、TLS 1.0 はサポートされていません。
-
-
curlDLB SSL エンドポイントに対して次のコマンドを実行します。
curl -vI --insecure --tlsv1.0 https://DNS of the SSL endpoint-
バックエンドサーバーまたは HTTP エラーコードから返された結果が表示される場合、TLS 1.0 がサポートされています。
-
コマンドで
curl: (35) Server aborted the SSL handshake が返された場合、TLS 1.0 はサポートされていません。
-
制限事項
ECDSA ベースの認証暗号化を使用するには、ECDSA ベースのアルゴリズムを使用する証明書と鍵のペアを生成し、同じアルゴリズムを DLB の SSL 証明書と鍵の設定に適用します。
RSA ベースの証明書と鍵のペアで ECDSA ベースの認証暗号化を使用しようとすると、SSL ハンドシェイクが失敗し、次のいずれかのエラーメッセージが表示されます。
SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failureまたは
Error: write EPROTO 140434219616616:error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE:../../third_party/boringssl/src/ssl/tls_record.cc:594:SSL alert number 40 140434219616616:error:1000009a:SSL routines:OPENSSL_internal:HANDSHAKE_FAILURE_ON_CLIENT_HELLO:../../third_party/boringssl/src/ssl/handshake.cc:603:現在の DLB 設定で許可されているのは SSL エンドポイントごとに 1 つの種別の SSL 証明書と鍵のペアのみであるため、RSA ベースの暗号化を使用するクライアントは ECDSA ベースの設定に接続できず、ECDSA ベースの暗号化を使用するクライアントは RSA ベースの設定に接続できません。