I have to admit that I am not a pro on certificates or that I like working with them, but sometimes you have to deal with the things that you don’t ‘fancy’ too much.
The story
So we install Exchange 2010 and do all the poking around to make sure all the settings are correct. Ignoring the certificate portion even though reading about it, and voila, off to go and test how Outlook works on our client’s computer.
What happend?
A certification error pops up when we open Outlook on the client computer with a security alert saying ‘The name on the security certificate is invalid or does not match the name of the site.’
On some of the client computers, it blocks access to connect Outlook to the Exchange server after you click ‘Yes’ to continue.
Back to the Exchange server we try to see what certificate is causing the problem, when realizing that we have to set up a new certificate since our domain name is not matching the one in the certificate.
A couple of things to note:
1. We needed a certificate
2. It cost money
3. We needed a special certificate to handle multiple sub domain names
What is going on here?
Well, at first we need to understand how internal versus external certificates work.
When you navigate to a website outside your network, an external certificate is needed so here we need to use a third party vendor such as GoDaddy or VeriSign because the certificates are available on the web.
If we are inside our network and are using websites or applications which are hosted inside our network, we can use an internal certificate since it is available throughout our network. We just install the Certification Authority (CA) role on a server within our network and then we can generate our own certificates from there.
This answers the first two points above.
The third point addresses something called Subject Alternative Names (SAN).
In some cases, we have more than one domain name (local domain name or external). Such can be, in our case, mail.domain.com, Server01.domain.com, and autodiscover.domain.com.Instead of generating one certificate for each name, we can add Subject Alternative Names in the certificate.
So how do we solved this?
First, we installed the Certificate Authority (CA), Certificate Authority Web Enrollment, and the Online Responder Role on the server. It is recommended that you install it on a separate server in your domain and not the Exchange server.
Once we have the CA installed, we need to enable some functions in Internet Explorer on the Exchange server.
First we need to go to ‘Tools’ then to ‘Internet Options’ in Internet Explorer. We then need to select the ‘Security’ tab and click on ‘Trusted Sites’ icon. Click on the ‘Sites’ button and add the site ‘http://<CA Server Name>/certsrv/’ and uncheck the ‘Require server verification (https:) for all sites in this zone’.
Back to the parent window, we need to click the ‘custom Level…’ button and enable all of the options under the ActiveX controls and plug-ins. Also enable all items under the Scripting section. Remember to disable these settings once you are done with your certificates on your Exchange server.
Now we can navigate to the page ‘http://<CA Server Name>/certsrv/’ and select ‘Request a certificate’ then ‘advanced certificate request’ and then ‘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.’
On this page, we can paste the content of a request file and generate a local certificate.
By default, CA does not have the option to generate certificate which has multiple Subject Alternative Names (SAN), which we will need to generate our Exchange Certificate with multiple sub domain names.
To do this, go to the command prompt on the CA server, right click and run it as administrator.
Enter: certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 This will enable SAN for the CA.
Next, enter: net stop certsvc
Next, enter: net start certsvc
This will stop and start the CA service.
At this point, we need to see what certificates we have in our Exchange server. To do this, open Exchange Management Console and navigate to ‘Server Configuration’ and in the main top window, select the Exchange server.
Below we can find our Exchange Certificates file(s), and on each certificate, it will list what services are assigned to each certificate. On the right side pane, we have an option to create a new certification request.
What this does is that it prepares a request file that needs to be submitted to our internal CA server, and in return, it will generate a certificate which we can use in our Exchange server.
When we click on the ‘New Exchange Certificate’ and select what services we want to use for this certificate, it will generate a .req file which we can save on the desktop. We then have to right click this file and open it with notepad or WordPad and copy all of its content and paste it into the CA website on our Exchange server.
Once we click submit, the CA server will generate a .cer document which is our certificate file. Save this on the desktop and go back to the Exchange Management Console.
We can now see a certificate which does not have a blue icon with a white check mark in it. This is our pending certificate request which we have to right click and select ‘complete request’.
Follow the wizard, locate the .cer file and install it.
So now we have our new certificate installed and services assigned to it, but let’s verify if we have the correct certificate installed for the correct services to solve our dilemma with the certification error in Outlook.
To do this, we need to open Outlook on our client machine, and once or if the certification warning pops up, we need to click ‘View Certificate’, navigate to the ‘Details’ tab and scroll down to and click on ‘Subject Alternative Name.’ This should list all the DNS names which we want this certificate to be valid for.
If there are not names or the name is wrong, we can check the ‘Thumbprint’ and see what services are assigned to this Certificate in Exchange. Write down this sequence of characters or the first eight characters which we will need to compare with the certificates being used in the Exchange Management Shell (EMS).
Go back to the Exchange server and open Exchange Management Shell. Type: Get-ExchangeCertificate
This will list all the certificates installed and the thumbprint, services and subject name of each certificate.
Locate the thumbprint characters which we wrote down and look at the CN name that it is assigned to. Go back to Exchange Management Console and find the certificate being used. If it does not have the services we selected, we need to right click and assign the services to be used.
Follow the wizard and add at the minimum IIS to it.
That should be it.
No comments:
Post a Comment