Certificates are one of the biggest issues I keep hearing about with Exchange and OCS, and apparently I’m not the only one. Fellow MVP Michael B. Smith has recently posted two blog articles on certs: how to use SAN certificates with ISA 2006 and other certificate limitations. However, he’s got a couple of points on the second article that I’m confused about:
- According to this announcement on the Windows Mobile team blog, Windows Mobile 6.0 and up do in fact support wildcard certificates.
- The first point he makes is also head-scratcher, because I’ve also heard this was an issue, but I’d also recently heard of a workaround for it:
- In Outlook, go to the properties for your Exchange account (Tools, Account Settings, select your Exchange account and click Change) and click More Settings.
- On the Connection tab, click Exchange Proxy Settings.
- Look for the field Only connect to proxy servers that have this principal name in their certificate and make sure it’s checked (you may need to check the Connect using SSL only checkbox first).
- The value in this field should normally be set to msstd:server.external.fqdn, the FQDN the server is known as from the outside and that is the subject name of the certificate. So if my certificate was issued for 3Sharp, it would be msstd:mail.3sharp.com. To use this with a wildcard certificate issued to *.3sharp.com, this value would need to be set to msstd:*.3sharp.com.
I’m doing more checking, trying to figure out what the deal is here; in the meantime, if you’ve got operational experience with either of these issues, please let me know.
At any rate, there’s some more interesting factoids on certificates I’ve picked up:
- If you want to use a certificate with the Exchange 2007 UM role, you need to have a certificate on the machine whose subject name matches the server’s AD/DNS FQDN. It seems that you can’t enable a certificate for the UM service using the Enable-ExchangeCertificate cmdlet if this does not match. Note that you can do this for other services, such as those hosted by the CAS role; the cmdlet performs different name checks on the certificate based on the services (SMTP, POP3, IMAP, HTTP, and UM) that you are enabling.
- I’ve said it before, but it needs to be repeated: if you’re not using the default self-signed certificate, simply use the Enable-ExchangeCertificate cmdlet to move all services to one or more additional certificates. Do not delete the default certificate; although in most cases Exchange will simply recreate it when the appropriate service is restarted, you can cause subtle errors that will take a while to figure out.
- Learn more about certificate usage in Exchange in Creating a Certificate or Certificate Request for TLS.
- And learn more about the Enable-ExchangeCertificate cmdlet.