I just renewed the certificate for a client web store. This is a task that drives me crazy because I do it so infrequently that I can never remember the details. It's made worse by the fact that I use InstantSSL, a company whose documentation and practices are incredibly confusing. Also, cheap.
Here's what happened.
I followed the usual instructions for generating a Certificate Signing Request. This generated two files, a .csr and a .key (for later).
I used a command line like this:
openssl req -new -newkey rsa:2048 -nodes -keyout myDomainName.key -out myDomainName.csr
It is entirely unclear to me if the name of the files makes any difference. Also, in the dialog that openssl conducts to construct the CSR, it asks for "your name". It means 'your domain name'. May be obvious but I thought that maybe it was picking up the domain name from the command line.
The purchase process for InstantSSL is pretty easy. They are really good at taking money.
Since I screwed up the domain name thing, I had to interact with tech support and give them a new CSR. This was annoying since it just said I needed to do it, not how. Eventually I had looked around long enough that I felt like I had to call. Turns out you have to construct a support account and treat send it through the support website along with your order number.
The next step was validation. It does two things. It looks up the company phone number (in this case using Dunn & Bradstreet). I had to work with the client to be there to answer the phone and gather the 'validation code'. Entering this into the phone call tool triggers another email (this came to me, as the email address on the purchase) with another, longer validation code. This had to be put into the order control panel.
While there, I saw that it still wanted to send email to admin@, an address that does not exist, for additional validation. Turns out that, in the order control panel, you can change this to one of several other options. I don't know where they come from but, one of them was me. That sent another validation code to put into the order control panel.
And then I got an email with a .zip full of certification. Expanding this got me two files, a .crt and a .ca-bundle. I also needed the .key file made along with the CSR.
These were put into folders specified in the Apache config file. In my case, this was a virtual host file for that site.
There are three files and they need three entries for Apache configuration:
SSLCertificateFile /etc/ssl/certs/sales/myDomain.crt
SSLCertificateChainFile /etc/ssl/certs/sales/myDomain.ca-bundle
SSLCertificateKeyFile /etc/ssl/private/myDomain.key
On my system, these are root files with permission 644. I do not know if this is ideal. There might be some more secure arrangement. (That's what comments are for.)
After a server restart, the browser security violation went away and things look pretty good.
Now you know.