Authenticating with Certificates in EXTRA!

In EXTRA! sessions that use SSL/TLS or SSH protocols, client authentication may be handled by digital certificates. Certificates solve some of the problems presented by public key authentication, such as requiring the client to upload a copy of the public key to every server.

Your computer must be configured to recognize the server certificate presented by your host and, if necessary, to provide a client certificate for client authentication. If your computer is not properly configured, or if the certificates presented for authentication are not valid, you will not be able to connect.

Certificate Authority (CA) Signed vs. Self-Signed Certificates

EXTRA! accepts Certification Authority (CA) signed and self-signed certificates. CA signed certificates include an extension flag set that identifies them as such. For Certificate Authority signed server certificates, the Subject field identifies the server or user by name and the Issuer field identifies the CA that signed the certificate. Certificates that are used to authenticate the CA server certificate must be installed to the Trusted Root Certification Authorities store.

For self-signed certificates, the Issuer field must match the Subject field exactly. (In this case, the Subject is a host instead of a Certification Authority.) If the user accepts the validity of the self-signed certificate, it is installed to the Trusted Root Certification Authorities store manually or via a Windows group policy or login script.

The Authentication Process

Authentication may involve one or more processes, depending on the type of certificate you use and the security settings you've selected in EXTRA!. However, in all cases, EXTRA! checks the certificate to determine whether the date and digital signature is valid, critical extensions (such as extended key usage) are correct, and key usage allows the cert to be used for authentication.

Authentication may also include the following:

  • If the server identity needs to be verified, the client compares the host name in the session against the common name in the certificate.
  • If you use CA-signed certificates, EXTRA! verifies all certification authorities that are included in the certificate: the CA that issued the certificate; any intermediate CAs in the certification chain; and finally, the Trusted Certification Authority (or root CA). This is referred to as path validation.
  • (SSH connections only) If revocation checking is enabled, the client ensures that the certificate hasn't been revoked. See Configure Certificate Revocation Checking (SSH Only).
  • If server-side authentication is configured, the server requires the user (client) to present a certificate for authentication. Certificates used for client identity are stored in the user's Personal certificate store. For SSH connections, certificates can also be stored in the Reflection Certificate Manager.