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: