If you use custom SSL/TLS certificates for the Site Recovery Manager server endpoint certificate, the certificates must meet specific criteria.
Public certificate authorities (CAs) stopped issuing SSL/TLS certificates that contain internal server names or reserved IP addresses in November 2015. CAs will revoke SSL/TLS certificates that contain internal server names or reserved IP addresses on 1st October 2016. To minimize future disruption, if you use SSL/TLS certificates that contain internal server names or reserved IP addresses, obtain new, compliant certificates from your public CA before 1st October 2016. Alternatively, use a private CA to issue certificates.
Site Recovery Manager uses standard PKCS#12 certificates. Site Recovery Manager places some requirements on the contents of those certificates, but the requirements in this release are less strict than in previous releases of Site Recovery Manager.
Site Recovery Manager does not accept certificates with MD5 signature algorithms. Use SHA256 or stronger signature algorithms. If you are upgrading an existing Site Recovery Manager installation with which you use MD5 certificates, you must obtain a new certificate with a stronger signature algorithm before you upgrade Site Recovery Manager.
Site Recovery Manager accepts certificates with SHA1 signature algorithms but these are not recommended and result in a warning during installation. Use SHA256 or stronger signature algorithms.
The Site Recovery Manager certificate is not the root of a trust chain. It must not be a CA certificate.
If you use a custom certificate for vCenter Server and Platform Services Controller, you are not obliged to use a custom certificate for Site Recovery Manager, and the reverse.
The private key in the PKCS #12 file must match the certificate. The minimum length of the private key is 2048-bits.
The Site Recovery Manager certificate password must not exceed 31 characters.
The current time must be within the period of validity of the certificate.
The certificate must be a server certificate, for which the x509v3 Extended Key Usage must indicate TLS Web Server Authentication.
The certificate must include an
enhancedKeyUsageattribute, the value of which is
Unlike in previous releases, there is no requirement for the certificate to also be a client certificate. The
clientAuthvalue is not required.
The Subject Name must not be empty and must contain fewer than 4096 characters. In this release, the Subject Name does not need to be the same for both members of a Site Recovery Manager Server pair.
The certificate must identify the Site Recovery Manager Server host.
The recommended way to identify the Site Recovery Manager Server host is with the host's fully-qualified domain name (FQDN). If the certificate identifies the Site Recovery Manager Server host with an IP address, this must be an IPv4 address. Using IPv6 addresses to identify the host is not supported.
Certificates generally identify the host in the Subject Alternative Name (SAN) attribute. Some CAs issue certificates that identify the host in the Common Name (CN) value of the Subject Name attribute. Site Recovery Manager accepts certificates that identify the host in the CN value, but this is not the best practice. For information about SAN and CN best practices, see the Internet Engineering Task Force (IETF) RFC 6125 at https://tools.ietf.org/html/rfc6125.
The host identifier in the certificate must match the Site Recovery Manager Server local host address that you specify when you install Site Recovery Manager.
If Site Recovery Manager Server, vCenter Server, and Platform Services Controller run on the same host machine, you can use the same certificate for both Site Recovery Manager Server and Platform Services Controller. In this case, you must provide the certificate in two formats:
For Site Recovery Manager, the certificate must be a Personal Information Exchange Format (PKCS#12) certificate that contains both of the private and public keys.
For vCenter Server and Platform Services Controller, the certificate must be separated into two files, one for the certificate with the public key and one for the private key.
If you use a custom certificate that is signed by a third-party CA for which the root certificate is not registered by default in Windows, and you want the certificates to be trusted without the need for thumbprint verifications, install the root CA certificate in the Windows certificate store.