Use the
screen to establish and maintain the certificates presented for access to the PingFederate Bridge administrative console (or the administrative API) and for incoming HTTPS connections at runtime.The first system-generated certificate is the default certificate for both the administrative console and the runtime server. As multiple certificates are created, they can be activated (or deactivated) for the administrative console, the runtime server, or both. Additionally, any of them may be selected as the new default certificate for the administrative console, the runtime server, or both at a latter time.
When creating a certificate, additional domain names may be added through the use of the Subject Alternative Names field. Furthermore, if a user agent includes the host name that it intends to reach as part of the TLS handshake, PingFederate Bridge selects the applicable certificate based on the provided SNI (Server Name Indication) information. The selection looks at the common name and subject alternative names of each activated certificate. If PingFederate Bridge finds no match, it serves the default certificate. If PingFederate Bridge finds multiple matches, it serves the certificate with the better match. Consider the following sample configuration and inbound requests.
SSL Server Certificates configuration
Certificate | Common name | Subject alternative names | Activation status |
---|---|---|---|
#1 |
www.example.com
|
(None) | Administrative console and runtime server |
#2 |
www.example.org
|
*.example.org and
test.example.local
|
Administrative console and runtime server |
#3 |
www.example.info
|
*.example.info and
*.example.com
|
Administrative console and runtime server |
#4 |
admin.example.local
|
(None) | Administrative console (Default) and runtime server |
#5 |
runtime.example.local
|
(None) | Administrative console and runtime server (Default) |
Runtime behavior
Request type | Host name from SNI | Certificate served |
---|---|---|
Administrative or runtime | www.example.com | The host name from the SNI is an exact match to the common name
of certificate #1 and a partial match to the second subject
alternative name (*.example.org ) of certificate
#3.An exact match is a better match; therefore, PingFederate serves certificate #1. |
Administrative or runtime | www.example.org | The host name from the SNI is an exact match to the common name
of certificate #2. PingFederate serves certificate #2. |
Administrative or runtime | sso.example.org | The host name from the SNI is a partial match to the first
subject alternative name (*.example.org ) of
certificate #2. There is no other exact or partial
match.PingFederate serves certificate #2. |
Administrative or runtime | sso.example.info | The host name from the SNI is a partial match to the first
subject alternative name (*.example.info ) of
certificate #3. There is no other exact or partial
match.PingFederate serves certificate #3. |
Administrative or runtime | sso.example.com | The host name from the SNI is a partial match to the second
subject alternative names (*.example.com ) of
certificate #3. There is no other exact or partial
match.PingFederate serves certificate #3. |
Administrative | www.example.local | The host name from the SNI does not match any configured
certificate. PingFederate serves certificate #4, the default certificate for the administrative console. |
Runtime | localhost | The host name from the SNI does not match any configured
certificate. PingFederate serves certificate #5, the default certificate for the runtime server. |
If PingFederate Bridge finds multiple certificates of the same matching quality, it returns one of them in the TLS handshake. This response should not impact the user agent because either the common name or one of the subject alternative names matches the host name of the request. If PingFederate should always serve a particular certificate for any given host name, ensure that the common name and any configured subject alternative names do not overlap among multiple certificates.