About Us Products Services Partners Certification Testimonials Contact Us Support
Call Us :(718) 361-1010
Lansend Microsoft Certified Partner Microsoft Small Business Specialist

Installing a self-signed SAN SSL certificate on your Exchange Server

clock October 18, 2013 07:07 by author Ashwin Pai

Installing a self-signed SAN SSL certificate on your Exchange Server

There are many articles on the web about installing self-signed SSL certificates, but most of them assume multiple servers in a corporate environment & a certain level of knowledge and experience from the tech. It does not take into consideration the tech supporting an SBS server who has to deal with this issue once in a blue moon, when the SSL certificate expires on the server & Outlook et all start nagging. All you want to do is fix it & get out of there.

This article was pruned from the following three in-depth articles.

  1. How to create your own self signed SSL UCC SAN Certificate to use with Exchange 2007/2010
  2. How to add a Subject Alternative Name to a secure LDAP certificate MS KB 931351
  3. Issuing a Certificate for a Pending Request

In most SBS environments the Certificate server & the Exchange server are probably one and the same.
Nevertheless I have distinguished between the two by call the Certificate server as Certserver
If there is only one SBS server , then all references to a server are to the same Server

The Exchange server probably has an internal name & is on an internal domain name such as domain.local
Additionally you may have published the OWA on a different URL which to access the server from the Internet.
I have therefore referred to the Exchange Server in the following way. Please modify appropriately.

Internal name:

External name:

The same domain naming convention applies to autodiscover.

There are two text files attached to this post. You will need to download them & rename them accordingly.

request.txt (875.00 bytes)

Sancerts.txt (373.00 bytes)

  1. Sancerts.txt
    This file is a batch file & has to be run on the certificate server. It prepares the server to accept SAN requests. Presumably it has to be run only once during the lifetime of the server. Rename it to Sancerts.bat
  2. request.txt
    This is your request file. rename it to Request.inf & save it on the Exchange Server.



  1. Run the batch file Sancerts.bat on the Certificate Server , there is a pause at the end so you can verify that it was successful. If successful , press any key to close the Command window.
  2. Modify Request.inf to match your domain names & server names. If the inside & outside names & domain names are the same you need not duplicate entries.
  3. Open a command prompt on the Exchange server & navigate to the location where you saved Request.inf.
    Note: the process will create files & you should have rights to create files.
  4. At the command prompt, type the following command, and then press ENTER:
    certreq -new request.inf certnew.req.
  5. Type the following command, and then press ENTER:
    certreq -submit certnew.req certnew.cer
    You will get a popup asking you to select the Certificate server. It will probably be the same server
  6. If the above command is successful you will get a response that provides you the Request ID number to retrieve the certificate. Make a note of the number. Do not close the Window.
  7. On the certificate Server go to Administrative tools >>Certification Authority
  8. The above will bring up the CertSrv , go to Pending Requests ,  & issue the pending request , it should have today's date as you just requested it.
  9. Return back to the command prompt on the Exchange Server &type the following command, and then press ENTER:
    certreq -retrieve RequestID certnew.cer
    ReuquestID is the number you made of note of in step 6 above
  10. type the following command, and then press ENTER:
    certreq -accept certnew.cer

At this point if all goes well you have created  for & installed a new San certificate on the Exchange Server.

You now need to install this certificate on the OWA for the Exchange server ( See Image below)

  1. Open IIS Manager on the Exchange Server
  2. GO to Sites & select the site that hosts the OWA , in most instances it is the Default Website
  3. Click on Bindings in the Actions Menu on the right hand side.
  4. You should two https Types You will need to apply the certificate to both
  5. Highlight the first https & select edit a Window will pop up
  6. Under SSL certificate , use the drop down menu to select the certificate you just created
    Sadly I could not figure out a way to give it a friendly name so you may have duplicate entries of Internal.domain.local
    Select each one & click View to view the certificate & confirm that you have selected the correct certificate
    The correct certificate will have a validity date of one year from today
  7. Repeat 5 & 6 above for the other https
  8. Restart IIS & you should be done


The other SAD part is that I could not figure out how to assign the certificate for more than one year.

If anybody can figure that out please post on our Facebook page

I hate this nonsense of doing this every year
























Event ID: 27 While processing a TGS request for the target server krbtgt

clock May 12, 2012 12:59 by author Ashwin Pai

While processing a TGS request for the target server krbtgt XXXXXXXX
did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 8).
The requested etypes were 18.  The accounts available etypes were 23  -133  -128  3  1.

Event Type: Error
Event Source: KDC
Event Category: None
Event ID: 27

The cause of the event is that the client requests a service ticket with a etype 18 (aes256-cts-hmac-sha1-96), which is not supported by Windows Server 2003 but supported by Windows Server 2008 R2. If the Kerberos authentication works properly, you can safely ignore the events. It just informs the clients what etypes it supports.

For more information, please refer to the following articles:

The security principals and the services that use only DES encryption for Kerberos authentication are incompatible with the default settings on a computer that is running Windows 7 or Windows Server 2008 R2


Event ID 27 — KDC Encryption Type Configuration



The configuration of the AdminConnection\TCP protocol in the SQL instance BKUPEXEC is not valid.

clock September 15, 2010 06:42 by author Ashwin Pai
Event Type: WarningEvent Source: SQLBrowserEvent Category: NoneEvent ID: 3Date:  9/15/2010Time:  10:17:51 AMUser:  N/AComputer: SERVER NAME Description:The configuration of the AdminConnection\TCP protocol in the SQL instance BKUPEXEC is not valid. Cause: one of two reasons. 1. TCP/IP and Named Pipes is disabled Enable TCP/IP and Named Pipes using SQL Server Configuration Manager 2. Listening on the wrong IP address. This was our problem. Backup exec 11d was installed on Small business Server 2003  & the SBS Server also served as the VPN server. We disabled the VPN interface to stop  the SQL server from listening on the VPN interface. See 3rd IP below.  This worked for us  




    <<  April 2021  >>

    View posts in large calendar

    Sign in

    About Us Products Services Partners Certification Testimonials Contact Us Support Site Map Copyright © 2021. All Rights Reserved.