Planning for Certificates

One of the more difficult decisions when using public key infrastructure (PKI)–enabled applications, such as Lync Server 2013, is the decision to use internal or public certificates. In this context, internal is defined as coming from a Certificate Authority that is not automatically trusted by the operating system, whereas public means one coming from a Certificate Authority that is already present in the trusted root store of operating systems.

Lync Server 2013 uses certificates for the following purposes:

• External or remote user access to audio/video sessions, as well as conferencing and application sharing

• Remote user access for instant messaging

• Federation using automatic DNS discovery of partners

• Mutual Transport Layer Security (MTLS) connections between servers

• Transport Layer Security (TLS) connections between client and server

Regardless of whether internal or public certificates are used, the following requirements must be met:

• All server certificates must support server authentication (Server EKU [1.3.6.1.5.5.7.3.1])

• All server certificates must contain a valid and reachable Certificate Revocation List (CRL) Distribution Point (CDP)

• Key lengths must be either 1024, 2048, or 4096. Note that 1024-bit keys are not considered secure, so using them is not considered a best practice.

• All server certificates must use one of the following hashes:

• ECDH_P256

• ECDH_P384

• ECDH_P512

• RSA

Various Lync Server 2013 roles have specific needs around the names contained in the certificates. Luckily for administrators, the Certificate Wizard builds the certificate request automatically and accounts for pool names, fully qualified domain names of hosts, and simple URLs such as meet or dial-in that are created as a result of roles and features. The Lync Server 2013 administrator should ensure that the Certificate Authority to be used, whether internal or public, supports subject alternate names.