8

I've got an SSL certificate from GoDaddy, and it's time to renew. I ended up with a single "keystore" file, which I give to my webserver (Jetty). This is the process I went through to generate the original keystore file, which gets to my final point of confusion:

First I generated my keystore file:

keytool -keystore keystore -alias myalias -genkey -keyalg RSA -keysize 2048

Then I generated the certificate signing request (CSR):

keytool -certreq -alias myalias -keystore keystore -file myrequest.csr

I sent the myrequest.csr file to GoDaddy. They replied with two files:

example.com.crt
gd_bundle.crt

I then ran this step, which seems to be importing a portion of the GoDaddy cert into my keystore file, but not exactly sure how that works:

keytool -import -trustcacerts -alias myalias -keystore keystore -file gd_bundle.crt

Final step, similar to the above, pulling part of the domain cert into the keystore file:

keytool -keystore keystore -import -alias myalias -file example.com.crt -trustcacerts

Now I give the keystore file to my Jetty instance and all works fine.

With the renewal, I know I have to send GoDaddy another CSR. But do I start completely from scratch? Or was I supposed to keep around the original keystore file in step one, and proceed from there?

I didn't keep a copy of the original keystore file, I modified it via the steps listed above. So if I have to use it for a renewal, not sure if I got myself into trouble here.

Here's Jetty's doc for this which I used during the original keystore creation: http://wiki.eclipse.org/Jetty/Howto/Configure_SSL#Obtaining_a_CSR_from_keytool

1

2 Answers 2

12

Digital certificates as used for SSL/TLS have multiple components. While there are lots of details that we could examine, all we really need here is a high-level overview, but each piece is important to understand what you should do and why.

When you began the process of obtaining your certificate, you first issued the command,

keytool -keystore keystore -alias myalias -genkey -keyalg RSA -keysize 2048

You described this as "creating your keystore," which is accurate, but it did something much more important also: it generated your private / public key pair. In this case, the new keystore contained a key pair using the RSA algorithm and with 2048 bits of entropy (a fancy way of saying how strong the key is, or how long it might take to break relative to other keys). This is important because the key pair is how you will demonstrate to the Certificate Authority (CA) that your next request is a renewal, is really from you, and is for the same certificate.

When you generated your certificate request,

keytool -certreq -alias myalias -keystore keystore -file myrequest.csr

you created a file that contained your web site's information (foo.com), along with a bunch of other stuff - including your public key. It all got encoded into a well-known format and sent off to the CA. The CA generated your certificate using your public key and their private key, which is how some random web browser can use this to know that they are on your web site and that it's safe to send data. Your certificate gets validated by your private key, which only you have, and by the CA's public key, which only works if it matches up with the private key that signed the certificate.

So, how does all this play into accomplishing your goal of renewing your certificate?

The short answer is, you don't renew, because a renewal isn't really a renewal.

A "renewal" is just a fancy way of saying that you're requesting a new certificate, with a new expiration date, using the same private key as for the old certificate. If you use the same command as before (with the -certreq option), it will create a new certificate request using your existing key pair. Send that off to GoDaddy (or any other CA) and they should be able to process your request with no problem.

When they send the certificate to you, issue the import command and you're good to go:

keytool -keystore keystore -import -alias myalias -file example.com.crt -trustcacerts

You should be able to import the new certificate into the same keystore as the old certificate, since they have different serial numbers. If you run into problems with the import, try using a new alias. Since an alias is usually just for your own reference, you can change the alias or go in and remove the old certificate from the keystore. It won't be used anymore, so it's safe to remove, but it doesn't usually hurt anything to keep it around either.

Note: you won't have to run the CA root import again unless GoDaddy updated their root certificate (it does happen, but not very often). This was the command you used to bring in the root certificate:

keytool -import -trustcacerts -alias myalias -keystore keystore -file gd_bundle.crt

Since you mentioned that you're using GoDaddy, here's the link to their renewal page. The only instructions they have that are close to the Jetty server you're using are those for Tomcat. While those aren't exact, the Tomcat page does include some instructions on the use of keytool. GoDaddy Certificate Renewal support page

0

I had the same issue while renewing the certificate for our server at www.tpsynergy.com . After importing the new server certificate and restarting the tomcat, the error we were getting was ERR_SSL_VERSION_OR_CIPHER_MISMATCH. After lot of research, I used this link https://www.sslshopper.com/certificate-key-matcher.html to compare the csr (certificate signing request to the actual certificate). They both did not match. So I created a new csr and obtained a new certificate and installed the same. It worked.

So the full steps for the process are

  1. From the same server where the certificate will be installed, create CSR

    keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA -keystore tpsynergy.keystore
    

    (change the domain name as needed)

While creating this, it will ask for first name and last name. Do not give your name, but use the domain name. For example I gave it as www.tpsynergy.com

2.keytool -certreq -keyalg RSA -alias tomcat -file csr.csr -keystore tpsynergy.keystore

This will create a csr.csr file in the same folder. copy the contents of this to the godaddy site and create the new certificate.

  1. The downloaded certificate zip file will have three files

    gd_bundle-g2-g1.crt
    gdig2.crt
    youractualcert.crt
    
  2. You will need to download the root cert gdroot-g2.crt from godaddy repository.

  3. Copy all these files to the same directory from where you created the CSR file and where the keystore file is located.

  4. Now run the below commands one by one to import the certs into the keystore

    keytool -import -trustcacerts -alias root -file gd_bundle-g2-g1.crt -keystore tpsynergy.keystore
    
    keytool -import -trustcacerts -alias root2 -file gdroot-g2.crt -keystore tpsynergy.keystore
    
    keytool -import -trustcacerts -alias intermediate  -file gdig2.crt -keystore tpsynergy.keystore
    
    keytool -import -trustcacerts -alias tomcat  -file yourdomainfile.crt -keystore tpsynergy.keystore
    
  5. Ensure that server.xml file in conf folder has this entry

       <!-- Define a SSL HTTP/1.1 Connector on port 8443
         This connector uses the JSSE configuration, when using APR, the
         connector should be using the OpenSSL style configuration
         described in the APR documentation -->
       <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
          maxThreads="150" scheme="https" secure="true"
          clientAuth="false" sslProtocol="TLS"
    
          keystoreFile="/usr/share/tomcat7/webapps/productioncerts/tpsynergy.keystore"
          keystorePass="mypasswordsameas the one used while creating the csr"
       />
    
  6. Restart the tomcat

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .