Boswell's Q&A

Certificate Switches

Configuring certificates with the SelfSSL utility; plus, what NT admins plan to do with their orphanware.

• By Bill Boswell
• 10/19/2004

Question: I'm using your RPC over HTTP article and I have a small question. I'm setting up a small site for a client. We're using a self-signed certificate. How do I get SSLDiag to make the common name of the certificate correspond to the fully qualified domain name of their external interface, rather than the short name of the internal server?

The SSLDiag certificate works, but only for locally connected clients, not clients that connect using the external interface in their RPC proxy settings.

—Troy

Get Help from Bill Got a Windows or Exchange question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to Bill at mailto:[email protected]; the best questions get answered in this column. When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message but submit the requested information for verification purposes.)

Answer: If you want to generate a certificate with a specific FQDN, try the SelfSSL utility in the IIS Resource Kit. This is a command-line utility with a fairly straightforward syntax. Run it on the IIS server. Here's an example:

selfssl /t /n:cn=web1.company.com /k:2048 /v:1825

/t adds the certificate to the Trusted Root Certification Authority certificate repository on the IIS server. You'll need to export the certificate and import it on your clients to get RPC over HTTP to work. Use the certificate viewer in the IIS management console to export the certificate to a file that you can import to the clients.

/n specifies the common name (cn) for the site. In your case, you would enter the FQDN of your public interface, such as /n:cn=public.company.com.

/k specifies the bit size of the public key. Use 2048, because there are hypothetical attacks that could potentially succeed against a 1024-bit key.

/v specifies the time in days that the certificate will remain active. The default is seven days. Putting 1,825 days gives you five years. You may want to double this to 10 years, or 3,650 days. After all, if the self-signed certificate ever gets compromised, you can just issue another one at the server, then import the certificate to the clients. In a small network, this is not much of a problem.

If you want to assign the certificate to something other than the default Web site, you can specify a site ID. This is rarely necessary on an Exchange server because the RPC virtual folder is automatically assigned to the default web site (ID 0) and that is the default ID value for SelfSSL.

If you make a mistake or you want to change something in the certificate, just run SelfSSL again. It will replace the certificate currently assigned to the default Web site with a new certificate. You'll need to remove the old certificate from the local certificate repository. Use the Certificate snap-in inside an empty MMC console to view the certificate repositories. Drill down under Trusted Root Certification Authority to find the invalidated certificate and delete it.

Hope this helps!

Soon to be Orphanware
Well, the magic hour is fast approaching when support for NT will completely disappear. On Jan 1, 2005, there will be no more pay-per-incident support, Premier support, or Web-based support for NT 4.0, including security patches. You can find details at http://www.microsoft.com/ntserver/productinfo/availability/
retiring.asp.

How many of you are still running NT domains? How many of you still have a large number of NT servers still in operation? How do you plan on dealing with the Son Of The Bride Of Slammer II or whatever the next big security incident is called that affects NT services?

Write and let me know your plans. I'll print a selection of replies in an upcoming column.