I get the basic idea of public/private key pairs, but what I don't know is what is the inner workings of what IIS does when generating an SSL key.

One thing that makes me think there is more under the hood than just a PKI exchange, is that there are tools like OpenSSL that dig into webservers and expose different encryption abilities. These abilities appear be be based on some combination of Platform, WebServer, and Certificate signer.

Another thing I haven't actually figured out is what is the content of the key that Verisign/Comodo/etc will send me once the cert is generated. What are the security implications of that email, or can I just delete it since the key that matters needs to be exported from the IIS server.

Lastly, is the only way to get an SSL cert for a website to use IIS's control panel to create the keypair

1 Answer
1

For 3rd party Certificate Authorities like Verisign, how it works is you send them a Certificate Signing Request. The machine that generated the CSR also generated the Private Key. When they sign it, the file you get back only works in conjunction with the private key. That email is not critically important.

The base cryptography platform of the web-server determines what hashes, key-lengths, and capabilities it can support. OpenSSL is one platform, Microsoft's PKI infrastructure drives IIS is another.

For IIS7 (which is on Windows 2008) there is another way to handle the certificate-obtaining process. I'll describe how it works for a 3rd party CA.

Start -> Run -> MMC

Go to File -> Add/Remove Snap-in

Add the "Certificates" snap-in

When asked, select "Computer Account", on the local computer.

OK back to the main manager screen

Expand certificates, and expand "Personal" (if you already have SSL certificates in IIS, this is where you'll find them)