• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 70
  • Last Modified:

Exchange 2013 SSL certificates / UCC / external provider set up

Hi all.  I've got a complicated situation in which I am trying to cut some costs on (and thus implement what some would say is a slight bad practice).  This issue has multiple parts.

I recently did an exchange 2010 -> 2013 migration.  During that migration, I tried to download the GoDaddy UCC and import it into the Exchange 2013 ECP.  Each time I tried to import it, the process would finish but it would not show up in the list of available certificates.

Diving into MMC, I could see that the recently imported cert was there, but since Exchange couldn't see it - that was useless to me.  I worked around my issue by exporting the EX2010 certificate and importing that into Exchange 2013 (knowing that at some point in the near future I would have to do a new CSR and upload that to Godaddy etc.).  I saved myself the step at the time.

I've got two external web hosts that do white label service (XXXX.domain.com -> a web portal at an external host).  The first one, I just emailed the chain and Godaddy key and they set up the SSL cert.  All is working fine.
This second party is giving me issues.  I sent them the same data (.crt and the chain cert .p7b).  They came back asking me to put it in pfx format (which I did for them using a tool from GitHub).  During their import on IIS 8.5, it's claiming that the certificate does not include the private key.  Well, no kidding right?

So my question is:  How do I work with them on this?  I consider it truly a bad idea to export my private key from the Ex2013 server (assuming that I have done what I spoke about re: CSR and new cert download from GoDaddy) and send it to someone else.  Kinda defeats the point of the cert / trust yes?  Further, how was the other party able to complete it when this fellow is having issues?  Is there some advice I can lend them, or do I need to do something more?

If I'm indeed having a senior/blond moment, feel free to make fun of me endlessly.  It's 5pm local time, I've been going since 5am.

  • 2
1 Solution
Adam BrownSr Solutions ArchitectCommented:
Sounds like the second company is doing things incorrectly. The .CRT file that godaddy sends you is a full certificate that includes the private key. The P7B files are there for systems that require intermediary cert advertisement (load balancers, for instance). Usually the only thing you need to do to install a .crt is double click it, click the install option, and install it to the computer's private store. From there it will be available as a certificate. Using the import method in IIS or ECP will corrupt the data presented by the .CRT file Godaddy sends out. The only time you use PFX files is if you're importing an exported certificate through IIS or Exchange ECP.

Godaddy doesn't send a response completion file like they're supposed to, so you can't "complete" a certificate request in IIS or ECP using the stuff they send you. You just have to install the .crt file into the correct store.
browningitSysadminAuthor Commented:
I'll have to close this ticket leaving it a mystery.  I can't see the other admin's systems, sending them advice on the topic went nowhere.  I instead bought another cert on my own dime to resolve the issue.

For anyone that gets here based on my talk about the Exchange issue - I found a way to resolve that as I rekeyed a cert today:

1) Rekeying your cert or running into the same issue as above during a migration?
2) Hit the 'complete' button in ECP, and note that the status for the certificate does not change (stuck at pending verification even though you completed the process and imported the cert)
3) Go into MMC and load certificates.  Note the serial number of the cert that was most recently imported and has no friendly name.
4) Run exchange powershell and enter this command:  certutil -repairstore my "SerialNumber"     (no spaces required for the serial)
5)  Not necessary, but perform an IIS reset
6) Edit the cert in MMC and give it a friendly name if desired
7) Back in ECP, review the certs and note that the correct cert has been added with the new friendly name on another line.  The old cert request marked 'pending' is still there, but not irrelevant.
browningitSysadminAuthor Commented:
Other party in the situation described was required to provide more details.  It was pure guessing on my side; and the advice was useful but couldn't be tested thoroughly.

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now