I do have an idea about SSL, certificates and related security concepts but in my previous works, it was someone else (client IT) who did the preparation, request and installation of SSL certificates until lately when I had to do it myself. I also had experience with trial and self signed certificates but still some things are not the same of course (including the risk of messing something up).
It's not as difficult as it sounds but want to share a few things. [more]
For those not so familiar with SSL, I would suggest google or wikipedia but since providers are working their best to get the highest rank for search engines you might not get the best explanations and the one for wikipedia seems too technical so the following article might help : What is SSL and what are certificates (used google to search for it too so there could be better ones) and here's something from Verising too: Secure Sockets Layer
With that out of the way the first step would be to generate a Certificate Signing Request (CSR) that will be used to apply to Verisign.
For CSR generation, go to the following link and select your server : Verisign : Generating a CSR request. In my case it was IIS 6.0 on Windows Server 2003.
Since the site had an existing certicate with another provider (not Verisign), I figured it wouldn't matter if I generate a renewal request (an option in IIS Server Certificates wizard) despite the new provider since it is the private key that matters and it's still in the machine so I generated the renewal request, initiated the registration, submitted the CSR (copy paste in their application wizard) and payment was succesful.
Now here's my first issue. Verisign wouldn't/can't process the application because the common name (CN) embedded/inside the CSR request does not match the company registered as the owner of the domain we are trying to secure the certificate for. Note that this was not an issue in the previous provider but Verisign is more particular on this (which is a good thing). So remember, the CN for the request must match the owner name registered for the domain. If that is not the case then they do offer the following options:
1) Update the registrant/owner information in the domain register to match the CN
2) Generate a new request with the matching CN and registrant
3) A domain authorization letter that must be signed by the domain registrant or the employee of the domain registrant (and NOT the organizational contact in the request).
So moving forward, our best option was option 2.
Now, you can't create a new request without removing the old attached certificate. Problem. But not for long because Microsoft has a work-around in the following link : Renew/Create CSR while another certificate is still installed. Note that the title mentions Renew but how I just did it. Well if you'd notice the article it applies to IIS 5.0 and IIS 6.0 seems have been added the feature that you can renew without going thru the work-around. That is generating a renewal CSR wouldn't require that you remove the existing certificate. Since I need to create a new CSR then I did what was in the article. Had another existing unused website (note: website and not virtual directory) on that IIS so I didn't need to create a new website. Used that to generate the CSR, application to Verisign again.
Took some time and a number of follow ups before they were able to get back to us that they can't verify the technical telephone contact. That they can't find a publicly verifiable number for our client. So either:
1) A faxed copy of a recent telephone bill showing the Organization Name and telephone number
2) A notarized letter signed by the Organizational contact authorizing the technical contact to request/apply for the product/certificate.
The technical and organizational contact was the same in our case but we did send a notarized letter nevertheless. Hopeful but turned out that they won't accept the faxed copy of the letter with an embossed notary seal. They suggested to shade the seal, did resent via fax and email but no luck. The seal was local and not from the US and not so legible even with the hard copy so if they insist then created a new one.
After all hassle, finally got the request approved. Signed in to Verisign Certificate Center (you'd have the details when you registered the first time) and downloaded the keys. got the PKCS#7 certicate (with intermediate certificate authorities – CA) since it was the common one and it says unless you know what you need, use PKCS. And knowing that it had the intermediate CA information I went for it. Otherwise if you installed incorrectly without the intermediate CA when you needed to then the certificate would appear as invalid to the browser.
Saved the content of the certificate inside a *.cer file. Continued the work-around steps from the Microsoft link earlier, that is processed the pending request on the temporary (the other unused web site), certificate was installed only to be removed after wards. Note that this is the trick. The certficate was disassociated with the other web site but it was installed and the record remains in the machine for use in another website. So went the production website > properties > directory security > server certificate > replace cerficiate > find the certificate installed a while ago (take note of the serial number or the name if it's obvious), replace and finally your good to go. Verify the certificate by accessing from your browser (from another machine – not from the same server). Read the article again for the more details instructions if you're not that familiar yet.
Verisign costs more than others but I'd still go for it if I/client can afford it despite this experience. But I would highly2x suggest that if you have renew a certificate especially if moving providers, make sure you do it way earlier than the existing certificates expiration (~ a month) to cover unexpected issues.
And we're done. Gotta sleep. 🙂