Solved

Exchange 2013 - Generate a new CSR and replace an existing operational SSL cert

Posted on 2014-12-18
23
202 Views
Last Modified: 2015-01-09
Wanted to bounce this off someone else -  

On a recent Exchange 2013 deployment project, I moved email off a web-hosting providers POP3 platform to an in-house Exchange 2013 server at my building. The web-hosting service no longer manages our email, but still manages the business website (ex; www.xyz.com).  The MX records for mail.xyz.com which used to point to their location, now points to my building.

As I was in setup phase on the Exchange server, I chose a certificate "common name" of "xyz.com" as I was generating the CSR.  This along with my autodiscover and owa SANs names.  This has not proven to be a problem "so far" with OWA access nor the sending/receiving operations of Outlook, both internally and externally.  Email is working without any issues in this regard.

What I am having a problem with is Android and iPhone EAS connection profile creation. When I create the EAS profile on my Android - and enter my email address of "me@xyz.com", I'm getting a security warning "the name of the site does not match the name on the certificate". When I view the error, the cert is showing as issued to the web hosting company's TLD "*.webhoster.com" common name.

I spoke with the SSL Issuers support - they believe the issue to be the common name I chose of "xyz.com" during cert creation. If I run a cert check on xyz.com, it does show the cert common name as - *.webhoster.com, which ties back to the Cert error I'm getting on the droid phones.  When I run a cert check on "mail.xyz.com", the cert common name is listed as "xyz.com", which is what I used when the CSR was created.  The SSL issuer advised to run another CSR process on server and re-key into their system to generate a new SSL cert.  They also advised to make the common name on the new CSR process, "mail.xyz.com"  

Does this sound plausible as to what the root problem is?

Is running another CSR the next course of action?

If another CSR is required, is there any deletion of the existing certs on Exchange required prior? Not sure what management of the existing cert infrastructure needs to be done before the import of the new certificate.

Many thanks on any assistance.
0
Comment
Question by:hwtech
  • 9
  • 7
  • 5
  • +1
23 Comments
 
LVL 14

Expert Comment

by:Ben Hart
ID: 40508090
I'd agree with your SSL issuer, the CN should always be the host name of an exchange server or the externally accessible host name in my case.  I don't see how using only your domain name referred back to the hosting companies domain though.  That ones a bit tricky.. but at least geenrating a new CSR and getting them to re-key the cert is a fairly painless process.

I can't believe OWA does not also complain about the name mismatch.  What services are assigned to your certs?
0
 
LVL 57

Assisted Solution

by:Pete Long
Pete Long earned 100 total points
ID: 40508117
0
 
LVL 14

Expert Comment

by:Ben Hart
ID: 40508125
Oh forgot this part, No you do not have to delete any old or unused certificate in Exchange.  When you assign services, if an existing cert is currently assigned to SMTP for example and you want to override that with a new/updated cert you will be prompted so Exchange knows you are sure you want to change that.  But no you don;t 'have' to delete any of them.
0
 

Author Comment

by:hwtech
ID: 40509235
@Ben -  I don't see how using only your domain name referred back to the hosting companies domain though

I'm at a loss on that as well. What I'm even more confused on is remote configuration of Outlook 2010 clients RPC/HTTP works without a hitch. No cert errors, no hangups during the config phase - works and connects.  Same with OWA. No cert errors upon initial connection.  Perhaps there's something different in the underlying protocol execution where EAS differs from the process OA uses when android/outlook client devices are being configured remotely.

On your 2nd response - Thanks on that. My first run through having to do this SSL re-keying, coming from SBS, so wasn't sure.  

@Pete - Pete I have tons of your tech-tips archived, but somehow managed to miss this one. Step #9 pretty much states my issue - thank you.

=====

An additional question to either -

I'll schedule a maintenance window when I apply the cert to cover system downtime if any - but what would you anticipate as far as end-user impact when this new cert goes active?

Will existing OA connection profiles (internal/external) have to be reconfigured, or will they process the new cert w/o getting prompted, when they do the first connection after the new cert goes in?

I don't see where the OWA client connections would be an issue. And obviously no impact on my mobiles as they're not even working yet -

Much obliged for the assistance gentlemen -
0
 
LVL 14

Expert Comment

by:Ben Hart
ID: 40509274
I've typically applied/renewed cert issues during the day.  Maybe I'm more cavalier than most but I've not had any problems reported in the past by doing that.  While the thumbprint will change, if you are renewing a valid cert with a valid cert.  There should not be any service disruptions.
0
 

Author Comment

by:hwtech
ID: 40511571
Generated new CSR on my Exchange server. Submitted/approved/re-key'd and applied on my server - I'm still getting an SSL Cert error on my mobile when I attempt to configure.
 
CSR setup steps on my Exch-2013 Server :
Common Name: mail.xyz.com - (originally had xyz.com chosen as common name on 1st cert)
SAN: autodiscover.xyz.com
SAN: owa.xyz.com

Submitted to SSL provider (GoDaddy):
Common Name listed as: mail.xyz.com
SAN: autodiscover.xyz.com
SAN: owa.xyz.com

Completed Pending Request on Exch Server:
- Did not get prompted to rewrite an existing certificate (per PeteNet's Step 18)
- Did get warning prompt stating: "Do you want to enforce SSL communication on the root web site? If not, reun the cmdlet with the -DoNotRequireSSL parameter" - I chose yes on this prompt and have not run the cmdlet.
QUESTION - I have not installed the intermediate SSL cert that came with the re-key'd cert. Do I need to do this?
QUESTION - I still have the original SSL Cert that was giving me problems, displaying under Servers | Certificates - Can I delete this to keep my certificates listing clean and current?

- Assigned services IIS-SMTP to the new cert.
-IISRESET (and server reboot)
-Looking at the "General" properties on the new SSL Cert - SAN's listed are mail.xyz.com - www.mail.xyz.com - autodiscover.xyz.com - owa.xyz.com
QUESTION: Where did the www.mail.xyz.com SAN come from?

When I attempt to configure an EAS connection on my mobile (and I'm discovering now the OA configurations for remote users is hit and miss - originally stated these were connecting without issue), I'm getting the same error as listed above:

"the name of the site does not match the name on the certificate". When I view the error, the cert is showing as issued to the web hosting company's TLD "*.webhoster.com" common name.

Throwing up the white flag...help!
0
 
LVL 14

Expert Comment

by:Ben Hart
ID: 40512344
If you don't mind.. what is your OWA address? You can PM if you'd like but I want to see the error.

It really sounds as if Godaddy appended a WWW to that one name.  I've never used them so I don't know what their screens or processes are like.
0
 
LVL 31

Accepted Solution

by:
Gareth Gudger earned 300 total points
ID: 40512537
Sounds more like a DNS issue than a cert issue.

Before autodiscover devices go to autodiscover.yourdomain.com, they will attempt to resolve to just yourdomain.com first. Then they will see if 443 is open and if there is a valid cert. Sounds like they are finding one at yourdomain.com.

But rather than your Exchange server they are ending up at your web hosting provider. Normally this is a result of DNS entries at your hosting provider. They probably have a wildcard DNS entry in play, that redirects everything to WWW.YOURDOMAIN.COM. Kill this wildcard DNS entry that is forwarding everything to WWW. Probably a * (asterisk) or @ symbol. Then flush DNS (or reboot the device) and try again.

You can also try the autodiscover test at www.exrca.com.
0
 
LVL 14

Assisted Solution

by:Ben Hart
Ben Hart earned 100 total points
ID: 40512966
In addition to what Gareth says above: From mxtoolbox I see two mx records for that domain.  I'd say that obviously you should make sure that the second one: cluster5a.us.messagelabs.com is correct, if not get it removed from your external DNS.
And the reverse DNS record has mismatched host names.. verify the hostname on that new Exch vm that it matches the MX record.
0
 

Author Comment

by:hwtech
ID: 40513929
I have a PTR request in to TW to point the IP to the MX record.

The secondary MX record was to the original hosting system and will be removed. Thanks on that.

Also have spoken to the web hosting provider. They host multiple customer sites and do have a wildcard that points to their TLD, that isn't specific to my domain site, but somehow is a catch-all that encompass' all customer domains they host. I'm not totally clear on what their setup is, so I'm probably not explaining it clearly.  They did setup an SRV record to see if that will eliminate the error, and escalating as to what their implication may be in all this, and what other options may be available. Will update when I have something back on this.

Did have an issue with proxy errors this morning on my OA clients. This occurred after I changed the common name y'day to mail.xyz.com. I had to re-run a Set-OutlookProvider EXCH command which took care of that issue.

Appreciate the assistance gentlemen and will update when I have something.
0
 
LVL 31

Expert Comment

by:Gareth Gudger
ID: 40513945
Ok great! An SRV record should fix the problem too, In fact, if the SRV record does work then you can drop autodiscover.yourdomain.com from your SSL if you want.
0
What Is Threat Intelligence?

Threat intelligence is often discussed, but rarely understood. Starting with a precise definition, along with clear business goals, is essential.

 

Author Comment

by:hwtech
ID: 40516618
Wanted to provide an update. The webhoster config'd an SRV record that pointed to my mail.xyz.com record - which has not resolved the issue. When I run an RCA test - I'm getting this:

==========
Attempting the Autodiscover and Exchange ActiveSync test (if requested).
       Autodiscover was successfully tested for Exchange ActiveSync.

      Additional Details
       
Elapsed Time: 7612 ms.
       
      Test Steps
       
      Attempting each method of contacting the Autodiscover service.
       The Autodiscover service was tested successfully.
       
      Additional Details
       
      Test Steps
       
      Attempting to test potential Autodiscover URL https://xyz.com:443/Autodiscover/Autodiscover.xml
       Testing of this potential Autodiscover URL failed.
       
      Additional Details
       
      Test Steps
       
      Attempting to resolve the host name xyz.com in DNS.
       The host name resolved successfully.
       
      Additional Details
      Testing TCP port 443 on host xyz.com to ensure it's listening and open.
       The port was opened successfully.
       
      Additional Details
      Testing the SSL certificate to make sure it's valid.
       The SSL certificate failed one or more certificate validation checks.
       
      Additional Details
       
      Test Steps
       
      The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server xyz.com on port 443.
       The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.
       
      Additional Details
      Validating the certificate name.
       Certificate name validation failed.
        Tell me more about this issue and how to resolve it
       
      Additional Details
       
Host name xyz.com doesn't match any name found on the server certificate CN=*.webhoster.com, OU=Domain Control Validated.
Elapsed Time: 52 ms.
=======================

They're suggesting possibly obtaining a new SSL cert for TLD xyz.com - assigning to however their web operations are configured, but also stated that 443 would also still remain open to the website they continue to host for us: www.xyz.com.

@Gareth - to your comment on a 443 probe against the domain xyz.com initiating first,  I think that is the issue. And if they create a new SSL cert, remove my xyz.com domain from their wildcard - If they do this, won't the port 443 probe still hit their website first? Once it hits their system, will they still need to maintain an SRV on their end that somehow redirects the autodiscover process down to my server at mail.xyz.com? I'm not clear on if this will resolve my issue, as if another cert has to be purchased, that's on me to pay for..Wanna make sure that's the solution if the SRV record they're attempting to get configured, doesn't work.

Curious your thoughts?  Thanks..
0
 
LVL 14

Expert Comment

by:Ben Hart
ID: 40522354
You mightve answered this already but don;t they host an external DNS record for autodiscover.domain.com for you?
0
 
LVL 31

Expert Comment

by:Gareth Gudger
ID: 40522480
Also have spoken to the web hosting provider. They host multiple customer sites and do have a wildcard that points to their TLD, that isn't specific to my domain site, but somehow is a catch-all that encompass' all customer domains they host. I'm not totally clear on what their setup is, so I'm probably not explaining it clearly.  They did setup an SRV record to see if that will eliminate the error, and escalating as to what their implication may be in all this, and what other options may be available. Will update when I have something back on this.

Do you have any visibility into your DNS records? Can you modify your own DNS records?

Sounds to me like its time to switch providers. Or move your DNS / domain to someone that can do this for you.
0
 
LVL 14

Expert Comment

by:Ben Hart
ID: 40522490
HA! I was having the same thoughts here.  I've never know GoDaddy to be so weird or troublesome in their DNS hostings.  Any chance you can host your own?
0
 
LVL 31

Expert Comment

by:Gareth Gudger
ID: 40522494
Yea if he can just kill the wildcard catchall record it would be resolved.
0
 
LVL 14

Expert Comment

by:Ben Hart
ID: 40522499
And while he's in there might as well setup an SPF.
0
 

Author Comment

by:hwtech
ID: 40522567
Dealing with the web hosting provider who still manages the website. I have no visibility into DNS and have to work through them on any record mods. Reluctant to move DNS, but Friday submitted a request to create an SSL and pull the domain out from underneath their wildcard umbrella.

Found this article last Friday which talks to the very issue I"m having. If I load up an https://domain.com - I'm getting a cert error and landing on one of their default pages. From what the last section of this article states, if this happens, it dies there and never trips to the autodiscover record that is setup. Hoping like #$%@ this fixes my issue!

http://www.shudnow.net/2013/07/26/outlook-certificate-error-and-autodiscover-domain-com-not-working/
0
 
LVL 14

Expert Comment

by:Ben Hart
ID: 40522595
:NodsInAgreement:
0
 
LVL 31

Expert Comment

by:Gareth Gudger
ID: 40522600
Yep. That's the issue.
0
 

Author Comment

by:hwtech
ID: 40528278
Update - still awaiting final setup on this SSL cert. Will update once I have something to report.
0
 

Author Closing Comment

by:hwtech
ID: 40540735
SSL Certificate reinstall finalized today.

ExRCA tests are now showing a successful AUTODISCOVER query and POST against the EXCH-2013 server. As pointed out, it first attempts to run an AUTODISCOVER against the TLD domain, and ultimately fails. It next rolls to the AUTODISCOVER DNS record established, running a successful URL query and POST. Sweet.

The ExRCA is flagging an *Analyzing the certificate chains for compatibility problems with versions of Windows* warning. But from what I understand, this is mainly for informational purpose only, and no impact on the successful run of the AUTODISCOVER process.

Much obliged gentlemen for the assistance. Gareth ultimately pointed me in the proper direction on this certificate name mismatch issue. Will divvy up the points accordingly but all assistance was of great value.
0

Featured Post

Top 6 Sources for Identifying Threat Actor TTPs

Understanding your enemy is essential. These six sources will help you identify the most popular threat actor tactics, techniques, and procedures (TTPs).

Join & Write a Comment

Local Continuous Replication is a cost effective and quick way of backing up Exchange server data. The following article describes the steps required to configure Local Continuous Replication. Also, the article tells you how to restore from a backup…
This process describes the steps required to Import and Export data from and to .pst files using Exchange 2010. We can use these steps to export data from a user to a .pst file, import data back to the same or a different user, or even import data t…
In this video we show how to create a User Mailbox in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Recipients >> Mailb…
The basic steps you have just learned will be implemented in this video. The basic steps are shown to configure an Exchange DAG in a live working Exchange Server Environment and manage the same (Exchange Server 2010 Software is used in a Windows Ser…

757 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

23 Experts available now in Live!

Get 1:1 Help Now