|Applies To||Adaptive Authentication OnPrem|
|Issue||This article explain authentify certificate renewal process and necessary actions from customers.|
|Notes||1 Introduction |
The intent of this article is to provide options for leveraging SSL with Authentify Services.
The document also provides details on Authentify certificate renewal and rollout process.
Authentify requires secure HTTP communication to connect with the Authentify service. We support both server-side only (1-way) SSL authentication and mutual (2-way) SSL authentication. This document specifies Authentify’s practices in managing our SSL certificates and validating client certificates; and provides recommended customer practices for ensuring reliable and secure SSL based communication.
2 Server-side SSL Authentication (1-way SSL)
Authentify leverages standard SSL Protocol to establish an encrypted channel prior to exchanging message traffic. 1-way SSL requests should be sent to the specific URLs provided in Section 2.1.
With 1-way SSL, the client or requesting application verifies the server (Authentify) SSL certificate only; no client certificate validation occurs.
2.1 How to initiate 1-way SSL requests to Authentify
See also Section 4 regarding validating the Authentify server certificate.
3 Mutual SSL Authentication (2-way SSL)
Customers can choose to use mutually authenticated SSL when exchanging messages with the Authentify service, when it is required that the Authentify server verify the originating server’s certificate. Authentify leverages the standard Mutual SSL Protocol to establish an encrypted channel and verify identity prior to exchanging message traffic.
When making a mutual SSL connection, the Authentify server will request a SSL certificate from the client. The presented client certificate chain is validated before the handshake is completed. See Section 3.2 for validation criteria
3.1 How to initiate 2-way SSL requests to Authentify
Use the following service URLs to initiate 2-way SSL requests within each environment:
- Implementation / Development - https://imp.authentify.com/certs2s/default.asp
- Quality Assurance / User Acceptance Testing - https://certs2s.alpha.authentify.com/s2s/default.asp
- Production - https://certs2s.trans.authentify.net/s2s/default.asp
3.2 How Authentify validates client certificates
The originating server requesting using mutual authentication must present a valid client certificate to the Authentify service. A client SSL certificate must pass the following validation rules:
- Certificate must be issued by a recognized CA and have a valid signing chain. Authentify accepts certificates from the following CAs: Verisign/Symantec, Geotrust, Comodo, Entrust
- Certificate must not be expired
- Certificate attributes match what was agreed to at the time of implementation (rules are coded into the application script). Attributes can include any combination of:
CN = Client Common Name , OU = Client Organizational Unit, O = Client Organization
Note 1: When a client SSL certificate is renewed the customer must take proactive steps to ensure the new certificate will pass Authentify’ s validation rules. Authentify will endeavor to keep its CA bundle current with intermediate signing certificates for the CAs listed above; however the customer should provide a copy of its public certificate to Authentify so we can verify in advance of deployment. If there is any change in the attributes listed above that are being validated, provide notice to Authentify.
Note 2: If the Authentify script for a customer’s application is implemented with certificate attribute validation for mutual authentication, the customer will not be able to use that application with our 1-way SSL URL. The transaction will fail transaction validation since the Authentify server would not have requested the client certificate to pass to our service.
4 How to validate the Authentify certificate
Customers can validate Authentify’ s SSL certificate using one or more of the following methods:
It is not recommended to perform serial number validation, as every certificate renewal will trigger configuration changes on every server that connects to the Authentify service.
5 Certificate Renewal Process
Authentify Support will inform customers in advance of a certificate renewal. Public certificates will also be provided upon request.
Customer required action: Customers will need to allow new and old certs simultaneously for a minimum of 48 hours, beginning at the time of the certificate renewal.
5.1 Authentify Certificate Renewal Process
[Process is invoked in advance of certificate expiration]
Authentify intends to notify customers when the certificate renewal process begins in order to provide ample lead time for the planned change. Production renewals will have at least 5 weeks’ advance notice. The renewal process steps follow:
Authentify retains the right to install certificates according to a schedule deemed appropriate.
In the unlikely event that a certificate is compromised, the above-mentioned schedule will be adjusted in order to immediately restore security to standards.
6 How does Authentify protect its SSL certificates?
Authentify protects its SSL Certificates with VeriSign’s MPKI (Managed PKI for SSL) product portal. Managed PKI for SSL provides both centralized control and delegated administration. Managed PKI for SSL security is such that certificates requested for the Authentify.com and Authentify.net domains can only be issued via the MPKI portal. Certificates issued for these domains cannot be issued via VeriSign’s main website channel.
The MPKI portal requires an authenticated log in by an authorized Authentify employee in order to submit an order for a new certificate. This log in attempt is authenticated using an Administrative Certificate that is generated by VeriSign and installed locally on a machine for use by the browser. This Administrative Certificate expires biannually