LiveZilla Live Chat Software

How to create a self-signed SSL certificate for Exchange 2003/2007/2010 on Windows Server

Written by Mike Ambrosone on . Posted in Best Practices

I’ve recently tried a number of GroupWare platforms (among others: Zimbra Open Source Edition and of course Microsoft Exchange) to integrate Vircom’s Anti Spam Software, modusGate. I’ve been a long time adopter of Linux (in particular Ubuntu, or Red Hat before) for servers so I was very familiar with openssl and the creation of certificate requests, local certificate authorities and self-signed certificates. But creating a self-signed certificate for Exchange 2003-2007-2010 on Windows? No idea! It ended up to be pretty easy actually but I still spent way too many hours figuring it out. Hopefully, this article will guide you in the process to avoid you waste as much time as I did.

My test environment was similar to that of many organisations: the mail/groupware server is part of a LAN domain (MyNetwork) and subnet (/24), has an NetBios name (WellsFargo), a fully qualified internal hostname (wellsfargo.mynetwork.local) and a fully qualified hostname for public and external use ( I won’t get into the basics of managing multiple domains (internal/external) and assume you are familiar with the situation.

One of the requirements for the SSL certificate is that it has to work both internally (for employee’s computers on the LAN) and externally for public/roaming access (employees on the road, work at home). Since the default Exchange setup creates a certificate that is bound only to the local hostname (wellsfargo) and fully qualified hostname (wellsfargo.mynetwork.local), browsers and mobile devices popped up SSL certificate errors (identity theft) or just plain failed (Android mobile) when accessing the webmail externally on

Self-signed certificates are generally not recommended for production environments because they will make browsers issue a warning about the certificate not being issued by a recognized CA (Verisign, Thawte, etc.) but given the extreme price CA charge for SSL certificates, there are a couple scenarios when it totally makes sense:

  • For a Limited Access environment: there are a number of known computers that will access the webmail. You just need to install the certificate (and its CA cert) on each computer that will access the https server
  • For a Test environment

Here is a step-by-step guide and how to create your own self-signed certificate (for free) using Windows (I used 2003 but this should work on 2008 as well) and Exchange 2003-2007-2010.

(1) Open an Exchange Management Shell (go to the Start Menu -> Microsoft Exchange). You can also start a standard Powershell 2.0 Console and load the Exchange addin by issuing the PS cmdlets:
[PS] C:\> add-PSSnapin *exchange*
[PS] C:\> Get-PsSnapIn -Registered
(2) Within the Exchange Management Shell (EMS) List the existing certificates and the services they are enabled for using:
[PS] C:\>Get-ExchangeCertificate
Thumbprint Services Subject

————— ———— ———-

27A2E4F546791A7D079E24FAD2EC4599B8D95152 IP.WS CN=wellsfargo
(3) In EMS, create a new Certificate Request with Alternate Domain Names (for your internal and external hostnames)
[PS] C:\> New-ExchangeCertificate -generaterequest -subjectname “dc=com,dc=mycompany,o=My Company Inc,” -domainname,webmail.mynetwork.local,wellsfargo.mynetwork.local,wellsfargo -PrivateKeyExportable $true -path certrequest_wellsfargo.csr
You will now have a new Certificate Request that has been saved in the CSR file “C:\certrequest_wellsfargo.csr”. A new Get-ExchangeCertificate cmdlet command will show the new list of cerficates, which includes the new certificate request. At this point, the CSR has not been certified, so it can be used.

NOTE: There are many other ways to create a Certificate Request on Windows and IIS but I would highly recommend this method as this is the only one I could find that lets you specify a list of alternate domain names (which is a requirement for multiple organisations running internal/private and external/public networks in parallel).

(4) In order to perform the signing of the CSR, you will need to install Microsoft’s Certificate Services on your machine. To do so, open the Control Panel, go to Add/Remove Windows Components and make sure that “Certificate Services” is checked.

Windows will ask you if you want to install ASP. Hit “Yes” as it is required. The next screen will prompt you for the type of CA you want to setup. Select “Enterprise root CA” and click “Next”.

You will then be prompted to enter information about the Certificate Authority (CA):

  • Common name for this CA: wellsfargo.mynetwork.local
  • Distinguished name suffix: DC=mynetwork,DC=local
  • Validity period: 5 years

Click “Next”. The following screens lets you customize database and logs path, leave as default and hit “Next” again, and let Windows install the necessary components.

(5) We will now login to the Microsoft Certificate Server. Open up an Internet Explorer browser window (as I found out the MS Cert Server doesn’t fully support FireFox and I suppose, neither Chrome) and type this URL: “http://wellsfargo.mynetwork.local/certsrv” or, if your server is only configured to support SSL as is the default for a dedicated Exchange machine, “https://wellsfargo.mynetwork.local/certsrv”. You will be asked for your Domain credentials, enter them.

(6) Click the “Request a certificate” link and on the next screen click “advanced certificate request”. In the Advanced Certificate Request page, click the “Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.” option.

(7) Open the “” certificate request file you created in Step 2 in Notepad. It will look like this:

(8) Paste the complete certificate request into the “Saved Request:” box of the Microsoft Certifcate Services web page. Select “Web Server” for the “Certificate Template” and click “Submit”.

(9) Once your certificate has successfully signed and generated, select “Base 64 encoded” option and click “Download certificate”. Save the file on your computer as “C:\certselfsign_wellsfargo.cer

(10) Go back to the Exchange Management Shell (EMS) and Import the newly self-signed certificate:
[PS] C:\> Import-ExchangeCertificate -path c:certselfsign_wellsfargo.cer -friendlyname “My Company WellsFargo”
(11) Verify the certificate has been properly imported and retrieve its Thumbprint with:
[PS] C:\> Get-ExchangeCertificate
Thumbprint Services Subject
————— ———— ———-
9799CEEBEA4FFADE068FC73FE63EB0495DD4F8A0 ....., O=My Comapny Inc, DC=mycompany, DC=com
..... CN=wellsfargo.mynetwork.local, DC=mynetwork, DC=local
27A2E4F546791A7D079E24FAD2EC4599B8D95152 IP.WS CN=wellsfargo
The newly certificate is the one we registered the request for using the public hostname ( The other new certificate is the certificate for the CA we installed through Microsoft Certificate Services.

(12) The last step is about enabling the new certificate for all services we want to use. In our case, I will enable it for IIS (https), POP, IMAP and SMTP.
[PS] C:> Enable-ExchangeCertificate -thumbprint 9799CEEBEA4FFADE068FC73FE63EB0495DD4F8A0 -services “IIS,POP,IMAP,SMTP”
[PS] C:> Get-ExchangeCertificate
Thumbprint Services Subject
————— ———— ———-
9799CEEBEA4FFADE068FC73FE63EB0495DD4F8A0 IP.WS, O=My Comapny Inc, DC=mycompany, DC=com
..... CN=wellsfargo.mynetwork.local, DC=mynetwork, DC=local
27A2E4F546791A7D079E24FAD2EC4599B8D95152 ....S CN=wellsfargo

You’re now all done. Your internal “https://wellsfargo.mynetwork.local” and your external “” will both be valid certificates which will let your clients connect through Outlook, through Outlook Web Access (OWA) and through Outlook Anywhere (RPC over HTTPS) for mobile devices.

As noted earlier, browsers will still issue a warning that the certificate was signed by a recognized Certificate Authority (CA) such as Verisign or Thawte. You can override this warning by manually importing both the Webmail CER (certselfsign_wellsfargo.cer) and the CA certificate into all your client computers.

On Linux, I used to create and sign my certificate so they are valid for a couple years, in order to avoid having to recreate them periodically. This is something that I wasn’t able to do with this process. During the self-signed certificate creation, I never saw any option to specify an expiration date (or a duration). Does anyone know how ?


Trackback from your site.

Mike Ambrosone

Mike Ambrosone has been a hard working IT professional for over 12 years. So far, he’s almost done it all! From holding positions in Support, QA and Development, Mike’s tenacity, leadership skills and motivation have come to fruition in his new post as Technical Product Manager. He keeps a sharp eye on market driven requirements in the office and a sharp eye on F1 racing whenever he can!

Comments (3)

  • Robin Carlin


    I am Persistent, But at this point can we schedule for having this information correctly configured by taking remote access to my system and betting it done.
    I have invested years with this platform and am just about to write a privacy policy denying everyone access to all components.
    Can i now be included in my team?
    I Need to Configure SSL Certificates to Use Multiple Client Access Server Host Names.


  • Pascal Miserez


    Great article !
    A few commandes have though changed with Win2008 and Exchange 2010.
    The New-ExchangeCertificate cmd has to be split in two.
    PS : $data = New-ExchangeCertificate -generaterequest -subjectname “dc=ch,dc=miserez,o=Miserez,” -domainname,owa.miserez.local,mail.miserez.local,miserez -PrivateKeyExportable $true
    PS : Set-Content -path “C:\MyCertRequest.req” -Value $Data

    also Import-ExchangeCertificate cmd has to look like this :
    Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\certnew_miserez.cer -Encoding byte -ReadCount 0))

    Thanks again for your help.


Leave a comment

Whitepaper Downloads

  • Spam Industry terms
  • Antispam checklists
  • Tips and tricks
  • In depth research analysis


Customer Quote

Vircom's suppport representative was very helpful, and quickly helped me determine the cause of our authentication problem.

    Tom Pipes
    T6 Broadband