openssl req -new -newkey rsa:2048 -nodes -keyout mydomain.key -out mydomain.csr
This resulted in the creation of 2 files :
I submitted the mydomain.csr to godaddy and was able to get a zip file.
$ unzip godaddy.tomcat.zip
The gd_bundle-g2-g1.crt seems to be a bundle of the root and intermed cert. gdig2.crt seems to be an intermediate CA cert which is inside the gd_bundle-g2-g1.crt file, and 92b553a029b7b18c.crt seems to be signed for my csr.
Since I need to add this to tomcat now, I need to have a keystore. Adding a key to keystore is not as simple as it should be. I need to write the key to a pkcs12 keystore using the "openssl" command and then import the created keystore using the "keytool" command. http://stackoverflow.com/questions/906402/importing-an-existing-x509-certificate-and-private-key-in-...
STEP 3 : Get the certificate from the csr generated in STEP 1
openssl x509 -req -in mydomain.csr -signkey mydomain.key -out mydomain.crt
STEP 4: Create a pkcs12 keystore form the crt file(from STEP 3) and key (from STEP 1)
openssl pkcs12 -export -in mydomain.crt -inkey mydomain.key -name "mydomain.com" -out my.p12
STEP 5: Import the pkcs12 keystore to a java keystore using keytool
keytool -importkeystore -deststorepass changeit -destkeystore my-keystore.jks -srckeystore my.p12 -srcstoretype PKCS12
STEP6: Add certificates to the keystore
keytool -import -alias root -keystore tomcat.keystore -trustcacerts -file gd_bundle-g2-g1.crt
keytool -import -alias intermed -keystore tomcat.keystore -trustcacerts -file gdig2.crt # not necessary since bundled above
keytool -import -alias tomcat -keystore tomcat.keystore -trustcacerts -file 92b553a029b7b18c.crt
STEP7: I've made the changes to tomcat config as in https://in.godaddy.com/help/tomcat-generate-csrs-and-install-certificates-5239. But on trying to connect to 8443, I see:
$ curl "https://localhost:8443"
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
Please let me know how do I try to debug and solve this.