In Extra! sessions that use SSL/TLS or SSH protocols, client authentication may be handled by digital certificates An integral part of a PKI (Public Key Infrastructure). Digital certificates (also called X.509 certificates) are issued by a certificate authority (CA), which ensures the validity of the information in the certificate. Each certificate contains identifying information about the certificate owner, a copy of the certificate owner's public key (used for encrypting and decrypting messages and digital signatures), and a digital signature (generated by the CA based on the certificate contents). The digital signature is used by a recipient to verify that the certificate has not been tampered with and can be trusted. . 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.
If revocation checking is enabled, the client ensures that the certificate hasn't been revoked. See Configure Certificate Revocation Checking.
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.