Close this search box.

Self Signed SAN Certificates

Every now and then I find that it is necessary to apply self signed SSL certificates when implementing Exchange servers. Self Signed Subject Alternative Name (SAN) Certificates that is, because Exchange uses that kind of certificates since Exchange 2007.

The need for self signed SSL certificates can have different reasons. One of these reasons can be that a company has an internal Windows Active Directory™ DNS domain name, that this company does not own on the internet. As a result, no public Certificate Authority will enroll certificates with this DNS name for you. Another reason could be that you use a TMG/ISA system (or some other reverse proxy) to publish the Exchange environment, in which case it is not necessary to add all Client Acces (CAS) servers to the SAN certificate. On the TMG/ISA server we only need a SAN certificate with the public DNS names in the Exchange organization. Internally we distribute the Self Signed Certificate by means of an Active Directory™ policy, so the Exchange servers are ‘trusted’ internally.

By default a self signed SSL certificate is created on the Exchange server at install time. The problem with this certificate is that this certificate is not very configurable. You cannot change the ‘valid period’ for example. It is also possible to use an internal Certificate Authority, if one is available. The disadvantage to this is that the valid period of certificates enrolled by these CA’s is limited and can or may not be changed easily.

If you decide to use self signed Certificates for the internal Exchange environment, you probably want a very long valid period, or at least as long as the expected life span of your Exchange environment. An unexpectedly expired self signed SSL certificate can lead to big problems for a company that cannot respond to this quickly. (You can still create a new certificate every year if you want to though, but you don’t have to).

At the time when IIS6 was the latest IIS version, it was simple to create self signed SSL certificates by using selfssl.exe from the Microsoft IIS6 Resource Kit. You could not create SAN certificates with this and selfssl.exe is not supported with IIS7 and higher.

In 2010 SelfSSL7 has become available. This is a tool, created by Thomas Deml with which you can create self signed certificates in a way similar to selfssl for IIS6. But SelfSSL7 has more functionality, among which adding multiple DNS names to the SSL certificate. SelfSSL7 can be downloaded from here. SelfSSL7 is not the only tool available to create self signed SAN certificates, but I think it is the most intuitive one.

SelfSSL7 in practice

Imagine, you need a SAN certificate with the following DNS names:

  • autodiscover.mydomain.local
  • webmail.
  • casserver1.mydomain.local
  • casserver2.mydomain.local
  • casarray.mydomain.local

With the below command we can create the SSL Certificate and assign it in IIS.

/N    – DNS names in the certificate
(Also the name with which i twill be added to the certificates store)
/K    – Key Length
/V     – Valid time (18250 creates a certificate with a 50 year valid time!)
/I     – Configures IIS bindings
/S     – Site to configure
/P    – Port number
/A     – IP Adress
/T     – Trust Certificate (Add certificate to local Certificate store)
/Q    – Overwrite the present binding in IIS

The resulting SSL certificate looks like the one below.

(Mind the ‘Valid to’ value of april 28th 2061)

A very handy feature is the possibility to write the certificate to a .PFX file. This can even be performed on a system without IIS installed. The command below generates the certificate above and saves it to disk, without adding it to IIS. Subsequently the certificate can be imported at the webservers.

A dutch version of this post can be found here.

This article is part of the GWB Archives. Original Author: René Wieldraaijer

Related Posts