ワイルドカード証明書 (CN) のコモンネーム

ワイルドカード SSL 証明書は、同じドメイン名内で複数のサブドメインを確保しようとする場合のオプションと考えられています。これらの証明書は、ドメイン名フィールドにワイルdカード文字 (*) を使用して、同じベースドメインにリンクされた多数のサブドメイン（ホスト）を確保します。

例えば、 *.domain.com に発行されたスタンダードワイルカード証明書は、www.domain.com、mail.domain.com、info.domain.com などを安全確保しますが、mail.test.com は安全確保しません。

デフォルトでは、要求された証明書は、すべての適合ドメインにインストールされると想定されています。ただし、すべての DigiCert サポートされたウェブサーバでは、一部のルールで、証明書を適格ドメイン上でのみインストールする必要があると規定されています。

自動化要求が到着した場合、サーバは、要求で使用する CN または SAN に基づく適合サーバブロックを探します。

Nginx は server_name を、要求中にある CN または SAN と比較します。

適合 server_name がサーバブロック群中に見つかった場合、適合するすべてのサーバブロックは安全確保されます。

例えば:

上の例では、以下について自動化を要求する場合：

1. CN=*.abc-example.com – ポート 8010 と 8030 サーバブロックの両方を安全確保します。
2. CN=*.mail.abc-example.com – ポート 8020 サーバブロックのみ安全確保します。
3. CN={8010/8020/8030}.abc-example.com – 各サーバブロックのみ安全確保します。
4. CN=*.abc-example.com と SAN=*.mail.abc-example.com – すべてのサーバブロックを安全確保します。

自動化要求が到着した場合、サーバは、要求中で使用した CN または SAN に基づき適合 <VirtualHost> ブロックを探します。

Apache は ServerName と ServerAlias を要求中にある CN または SAN と比較します。

適合 ServerName または ServerAlias が仮想ホスト群に見つかった場合、適合するすべての仮想ホストブロックは安全確保されます。

例えば:

上の例では、以下について自動化を要求する場合：

1. CN=*.abc-example.com – ポート 552 と 553 仮想ホストブロックの両方が安全確保されます。
2. CN=*.mail.abc-example.com – ポート 551 仮想ホストブロックのみ安全確保されます。
3. CN={551/552/553}.abc-example.com – 各仮想ホストブロックのみ安全確保されます。
4. CN=*.abc-example.com と SAN=*.mail.abc-example.com – すべての仮想ホストブロックが安全確保されます。

IIS サーバは、自動化要求で使用した適合 CN または SAN は探しません。証明書は、要求された IP アドレスとポートのみにインストールされます。

例えば:

上の例では、以下について自動化を要求する場合：

1. IP/ポート=123.123.123.123:401、CN=*.example.com – 123.123.123.123 のみ安全確保されます。401 IP アドレスとポート。
2. IP/ポート=125.125.125.125:402、CN=*.example.com、SAN=*.mail.example.com – 125.125.125.125 のみ安全確保されます。402 IP アドレスとポート。
3. IP/ポート=127.127.127.127:403、CN=*secure.example.com, SAN=*.example.com — 127.127.127.127 のみ安全確保されます。403 IP アドレスとポート。

自動化要求が到着した場合、サーバは、要求中で使用した CN および/または SAN に基づき適合 <コネクタ> ブロックを探します。

Tomcat は SSLHostConfig hostName を、要求中にある CN および/または SAN と比較します。

適合 SSLHostConfig Hostname がコネクタブロック中に見つかった場合、適合するすべてのサーバブロックは安全確保されます。

例えば:

上の例では、以下について自動化を要求する場合：

1. CN=*.abc.example.com – ポート 182 コネクタブロックを安全確保します。
2. CN=*.example.com – ポート 183 コネクタブロックのみ安全確保します。.
3. CN=*example.com – すべてのコネクタブロックを安全確保します。
4. CN=*.secure.example.com と SAN=*.secure.example.com、*.blog.example.com、abc.example.com、*.login.example.com – ポート 184 コネクタブロックのみ安全確保します。

例えば、証明書をすべての SSLHostConfig ブロックで正常に自動化およびインストールするには、以下について自動化要求を行う必要があります。

CN=*.example.com と SAN=*.mail.test.com

自動化要求が到着した場合、サーバは、要求中で使用した CN または SAN に基づき適合 <VirtualHost> ブロックを探します。

IBM サーバは、ServerName と ServerAlias を要求中にある CN または SAN と比較します。

適合 ServerName または ServerAlias が仮想ホスト群に見つかった場合、適合するすべての仮想ホストブロックは安全確保されます。

例えば:

上の例では、以下について自動化を要求する場合：

1. CN=*.abc-example.com –  ポート 552 と 553 仮想 ホスト ブロックを両方とも安全確保します。
2. CN=*.mail.abc-example.com – ポート 551 仮想ホストブロックのみ安全確保されます。
3. CN={551/552/553}.abc-example.com – 各仮想ホストブロックのみ安全確保されます。
4. CN=*.abc-example.com と SAN=*.mail.abc-example.com – すべての仮想ホストブロックが安全確保されます。
5. CN=551.abc-example.com と SAN=securemail.abc.com – ポート 551 と 553 仮想ホストブロックのみ安全保護します。