We Keep Coding

can't get go daddy ssl certificate to work with spring boot

I have a certificate with a generated a CSR within go daddy.
I tried generating my own CSR to get a certificate for my domain.
I have followed their tutorial to generate a store with the CSR:
keytool -genkey -alias codesigncert -keypass -keyalg RSA -keysize 2048 -dname "CN=displayname,O=companyname,C=US,ST=state,L=city" -keystore codesignstore -storepass
But the godaddy rejected the generated CSR, so I used the one they generate.
After that I used this command from a tutorial at thomasvitale.com.:
keytool -import -alias <my alias> -file <downloadedcertificate file>.crt -keystore keystore.p12 -storepass password
The generated .p12 keystore wouldn't boot because spring said:
DerInputStream.getLength(): lengthTag=109, too big.
Reading a LOT on that I have found out it was the way the keystore was generated and the version of something. Because of that I had to generate another keystore.
To generate the current problematic keystore I tried following medium.com instructions:
Used this to generate the keystore:
keytool -genkey -alias <alias> -keyalg RSA -keystore <keystore.jks> -keysize 2048
Used this to generate a CSR:
keytool -certreq -alias <alias> -keystore <keystore.jks> -file <domain>.csr
Sent the CSR to generate the ssl certificates, downloading them using the tomcat option. Then imported the certificates:
intermediate certificate: keytool -import -trustcacerts -alias <alias> -file gd_bundle-g2-g1.crt -keystore <keystore.jks>
root certificate: keytool -import -trustcacerts -alias <alias> -file e2e56xxxxf40c7.crt -keystore <keystore.jks>
Then I created the pcks keystore this way:
keytool -importkeystore -srckeystore <keystore.jks> -destkeystore <keystore.p12> -srcstoretype JKS -deststoretype PKCS12 -deststorepass <password> -srcalias <src alias> -destalias <dest alias>
After that, my spring boot config to install the certificate is:
After comments on this question I changed to use the JKS and removed ciphers.
server:
port: 8443
ssl:
enabled: true
key-store-type: JKS
key-store: classpath:asgard_keystore.jks
key-store-password: generated
key-alias: asgard
After installing all those to the p12, the server started okay, but any requests to the server would yield: err_ssl_version_or_cipher_mismatch or SSL_ERROR_NO_CYPHER_OVERLAP
Capturing that in wireshark just said Alert 21 using TLS 1.2 Handshake Failure (40).
I'm using undertow as a server. I don't remember if I used the domain in the name and last name field of the CSR.
Decoding my CSR using digicert tool I got:
Common name
<my domain>
Organization
<my org>
Organizational unit
<my city>
City/locality
<my city>
State/province
<my estate>
Country
<my country>
Signature algorithm
SHA256
Key algorithm
RSA
Key size
2048
Seems I'm doing everything exactly like every single tutorial, and every time something fails :(
As per the comment on the question, the keytool -list calls:
keytool -list for the .jks:
Keystore type: jks
Keystore provider: SUN
Your keystore contains 3 entries
Alias name: asgard
Creation date: Dec 7, 2018
Entry type: trustedCertEntry
Owner: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Issuer: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Serial number: 7
Valid from: Tue May 03 07:00:00 UTC 2011 until: Sat May 03 07:00:00 UTC 2031
Certificate fingerprints:
MD5: 96<removed>:40
SHA1: 2<removed>B8
SHA256: 97:3A<removed>E9:76:FF:6A:62:0B:67:12:E3:38:32:04:1A:A6
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
< not relevant >
]
*******************************************
*******************************************
Alias name: intermediate
Creation date: Dec 14, 2018
Entry type: trustedCertEntry
Owner: CN=<removed>, OU=Domain Control Validated
Issuer: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Serial number: 5c<removed>
Valid from: Fri Dec 07 20:25:19 UTC 2018 until: Mon Dec 07 18:10:35 UTC 2020
Certificate fingerprints:
MD5: 31<removed>74:77
SHA1: 8D:<removed>:C0:F5:AE:0B
SHA256: 77:14:9<removed>8B:1D:67:46:1A:67:A2:72:2F:2F:9E:F2:16
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
< not relevant >
]
*******************************************
*******************************************
Alias name: server
Creation date: Dec 7, 2018
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=<removed>, OU=São Paulo, O=Ideas Farm, L=São Paulo, ST=SP, C=BR
Issuer: CN=a<removed>, OU=São Paulo, O=Ideas Farm, L=São Paulo, ST=SP, C=BR
< not relevant >
]
]
*******************************************
*******************************************
full report: pastebin report
I have removed parts of the response that I find not relevant. I found it weird that the pkcs (.p12) file reported as being a jks type.
Also, the files that I received form the certificate authority are:
5<removedhex>6b1b.crt
gd_bundle-g2-g1.crt
gdig2.crt.pem
The gd_bundle contains 3 certificates -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- three times. The other two are just one.

You have told java to use the certificate with an alias of asgard. I can see in your .p12 dump that "asgard" is actually a CA. Look at the owner:
Alias name: asgard
Creation date: Dec 14, 2018
Entry type: trustedCertEntry
Owner: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Issuer: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
I'm guessing that you actually want to tell spring to load your .jks file and specify an alias of codesigncert.
Also, delete your ciphers and enabled-protocols properties unless you have a good reason to override what spring sets up as defaults. Spring keep their defaults up to date with the latest security bulletins.
Finally, change your keystore password because the whole internet now knows what it is :)

I have solved the problem.
After fiddling A LOT with each certificate, I have found out that GoDaddy issues the certificate response and 2 equal intermediate certificates. Both come in the download package and there is no root certificate in there.
What happened is that I had a self signed dummy key, as stated in the comments and I didn't knew that I had to import the server certificate (the certificate response) with the same alias as my private key. I was importing with another alias thinking it was something else. My private key would remain self signed and not validated.
The errors I was getting about ciphers were because I was telling spring to use a certificate that was not a private key. Those don't support decoding the handshake.
Another problem that I faced is that godaddy doesn't provide the root certificate in the bundle you download. I was trying to add two intermediates, while the root was avaliable at a repository they had. After downloading and importing the correct root certificate, then I was able to import the private key validation certificate to the same alias as my dummy key.
So the solutin was simply to start with the JKS keystore used to create the CSR (one that contains only the private key I generated). Then add to it the root and intermediate certificates, and finally add the server cert (the one with the hex name), with the same alias as the private key.

How correct certificate is getting picked up in JKS in ssl handshake

Lets say I have a JAVA client app and it tries to connect to a server (example.com) over https. Client app has a trust store JKS , which has the server's certificate and some other certificates as well. In the hand shake process when server sends it certificate to this client app, how correct certificate will be picked up from the trust store jks. i.e based on what parameters java matches the certificate sent by the server with the certificates stored in JKS.

Matching is done by the certificate's Subject.
E.g. if you browse https://www.google.com/ and look at their certificate, it shows a certificate chain with:
Subject: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
Issued by: /C=US/O=Google Inc/CN=Google Internet Authority G2
Issued by: /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
Issues by: /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
* Actually obtained using openssl s_client -connect www.google.com:443 -showcerts
The certificate will be trusted if any of these are in your truststore.
You can scan the truststore like this (assuming you have grep):
keytool -list -keystore /path/to/cacerts -storepass changeit -v | grep "CN=GeoTrust Global CA" -B 4 -A 8
To get this kind of output:
Alias name: geotrustglobalca
Creation date: Jul 18, 2003
Entry type: trustedCertEntry
Owner: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US
Issuer: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US
Serial number: 23456
Valid from: Tue May 21 00:00:00 EDT 2002 until: Sat May 21 00:00:00 EDT 2022
Certificate fingerprints:
MD5: F7:75:AB:29:FB:51:4E:B7:77:5E:FF:05:3C:99:8E:F5
SHA1: DE:28:F4:A4:FF:E5:B9:2F:A3:C5:03:D1:A3:49:A7:F9:96:2A:82:12
SHA256: FF:85:6A:2D:25:1D:CD:88:D3:66:56:F4:50:12:67:98:CF:AB:AA:DE:40:79:9C:72:2D:E4:D2:B5:DB:36:A7:3A
Signature algorithm name: SHA1withRSA
Version: 3

Setup to avoid PKIX path building failed error

Sorry for opening another question with the same topic, but i think this sub-question would bloat the other one into oblivion.
I run into the mentioned error message, which is quite unspecific (at least for me). The debug output shows the certificates are loaded and then only the mentioned error. I generated the test certificate with its own CA chain:
CA -> SubCA -> ClientCert
I try to connect a client and a server on the same machine (to test a two way protocol) with SSL.
I generate my ca certificates using these commands:
openssl req -batch -x509 -config ${ROOTCA_CONFIG} -newkey rsa:2048 -sha1 -nodes -out ${ROOTCA_CERT} -outform PEM -days 7300
openssl req -batch -config ${SUBCA_CONFIG} -newkey rsa:2048 -sha1 -nodes -out ${SUBCA_CSR} -outform PEM
openssl ca -batch -config ${ROOTCA_CONFIG} -policy signing_policy -extensions signing_req_CA -out ${SUBCA_CERT} -infiles ${SUBCA_CSR}
They seem to be fine. The only thing that puzzles me is: If concatenate both certificates into a single file and verify them with that chain, it is fine. If it try to verify with subCA or the root CA only, verification fails.
Then i create my client/server cert:
openssl req -batch -config ${CLIENT_CONFIG} -newkey rsa:2048 -sha256 -nodes -out ${CLIENT_CSR} -outform PEM -keyout $1.key
openssl ca -batch -config ${SUBCA_CONFIG} -policy signing_policy -extensions signing_req -out ${CLIENT_CERT} -infiles ${CLIENT_CSR}
With this i create a PKCS12 file to use in my keystore:
openssl pkcs12 -export -inkey ${CONNECTOR_KEY} -in ${CONNECTOR_CERT} -out ${CONNECTOR_P12}
I do this by calling my script twice, once for the server and once for the client. Let's call them client.cert and server.cert, even if client/server is confusing since they both are local protocol endpoints.
I then use these commands to generate the truststore and keystore for client and server:
keytool -keystore $2-truststore.jks -importcert -alias ca -file test_ca_certs/rootca.cert
keytool -keystore $2-truststore.jks -importcert -alias subca -file test_ca_certs/subca.cert
keytool -v -importkeystore -srckeystore $1 -srcstoretype PKCS12 -destkeystore $2-keystore.jks -deststoretype JKS
Let $2 be client and server each (server-truststore etc.) and $1 be the same as ${CONNECTOR_P12} before (somefile.p12)
So now i have a truststore with CA and SubCA and a keystore with the PKCS12 Token. Truststore is the same on client and server side, Token is pretty much the same, but has different keypairs, since they are generated each time.
The ssl debug output indicates the certs are loaded:
keystore (...) has type [jks], and contains aliases [1].
***
found key for : 1
chain [0] = [
[
Version: V3
Subject: CN=cnname, OU=ouname, O=oname, L=location, ST=bavaria, C=DE
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
Key: Sun RSA public key, 2048 bits
modulus: 2999...
public exponent: 65537
...
...
keystore has type [jks], and contains aliases [ca, subca].
adding as trusted cert:
Subject: CN=my Root CA 2016, O=organization, C=DE
Issuer: CN=my Root CA 2016, O=organization, C=DE
Algorithm: RSA; Serial number: 0xfc8239c0355555c1
Valid from Wed Oct 19 10:14:36 CEST 2016 until Tue Oct 14 10:14:36 CEST 2036
adding as trusted cert:
Subject: CN=my SubCA 2016, O=Fraunhofer, C=DE
Issuer: CN=my Root CA 2016, O=Fraunhofer, C=DE
Algorithm: RSA; Serial number: 0x1
Valid from Wed Oct 19 10:14:38 CEST 2016 until Thu Oct 17 10:14:38 CEST 2024
Is there some general flaw in my understanding? Again, sorry for posting two questions but i start to believe i do something wrong in a more fundamental fashion. Thanks!

I finally found the solution. I only set debugging to SSL. This was my mistake. I would have needed to set the debug output to "all". Then i can see this error message:
Caused by: sun.security.validator.ValidatorException: Extended key
usage does not permit use for TLS server authentication
This is much more specific. To fix that, indeed i needed to change my extended key usage to this:
keyUsage = digitalSignature, keyEncipherment, nonRepudiation
extendedKeyUsage = clientAuth, serverAuth
Thank you very much!

Glassfish, Java email and certificate

I've search far and long and can't find the answer.
I'm using Glassfish and want to send an email via our smtp server.
I've obtained the server's certificate:
openssl s_client -connect mail.example.com:587 -starttls smtp > our.cer
I've cleaned up the cer file to only contain the certificate data.
I've import it everywhere:
keytool -import -alias mail.example.com -file our.cer -keystore c:\Progra~1\Java\jre7\lib\security\cacerts
keytool -import -alias mail.example.com -file our.cer -keystore c:\Progra~1\Java\JDK17~1.0_4\jre\lib\security\cacerts
keytool -import -alias mail.example.com -file our.cer -keystore c:\PROGRA~1\GLASSF~1.0\GLASSF~1\domains\domain1\config\cacerts.jks
But I get the following error:
javax.mail.MessagingException: Could not convert socket to TLS;
nested exception is:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
...
Caused by...
...
Caused by...
...
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
My code snippet:
...
Properties properties = System.getProperties();
properties.put("mail.smtp.starttls.enable", "true");
properties.put("mail.smtp.host", "mail.example.com");
properties.put("mail.smtp.user", "example#example.com");
properties.put("mail.smtp.password", "some.password");
properties.put("mail.smtp.port", "587"));
properties.put("mail.smtp.auth", "true"));
properties.put("mail.smtp.from", "example#example.com"));
properties.put("mail.transport", "smtp"));
...
Authenticator mailAuthenticator = new Authenticator()
{
#Override
protected PasswordAuthentication getPasswordAuthentication()
{
return new PasswordAuthentication(properties.getProperty("mail.smtp.user"),
properties.getProperty("mail.smtp.password"));
}
};
try
{
// Get the default Session object.
Session session = Session.getDefaultInstance(properties, mailAuthenticator);
MimeMessage mimeMessage = new MimeMessage(session);
mimeMessage.setSubject("Hallo world!");
mimeMessage.setFrom(new InternetAddress(properties.getProperty("mail.smtp.from")));
mimeMessage.setRecipient(Message.RecipientType.TO, new InternetAddress("example#example.com"));
mimeMessage.setText("Some text message...");
Transport transport = session.getTransport(properties.getProperty("mail.transport"));//"smtp"
int port = Integer.parseInt(properties.getProperty("mail.smtp.port"));//587
transport.connect(properties.getProperty("mail.smtp.host"),//"mail.example.com"
port,
properties.getProperty("mail.smtp.user"),//"example#example.com"
properties.getProperty("mail.smtp.password"));//Clear text password
transport.sendMessage(mimeMessage, mimeMessage.getAllRecipients());
LOG.info("...done sending email");
}
catch (AddressException e)
{
LOG.log(Level.SEVERE, "Error while sending email", e);
}
catch (MessagingException e)
{
LOG.log(Level.SEVERE, "Error while sending email", e);
}
catch (Exception e)
{
LOG.log(Level.SEVERE, "Error while sending email", e);
}
I've also tried Mkyong's suggestion to run InstallCert (source) against the mail server but I get:
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
UPDATE 1
I've loaded the certificate in the following additional places:
keytool -import -alias mail.example.com -file our.cer -keystore c:\PROGRA~1\GLASSF~1.0\GLASSF~1\domains\domain1\config\keystore.jks
keytool -import -alias mail.example.com -file our.cer -keystore c:\GLASSFISH\config\keystore.jks
keytool -import -alias mail.example.com -file our.cer -keystore c:\GLASSFISH\config\cacerts.jks
I've also set these properties:
System.setProperty("javax.net.ssl.keyStore", "c:\\GLASSFISH\\config\\keystore.jks");
System.setProperty("javax.net.ssl.keyStorePassword", "changeit");
System.setProperty("javax.net.ssl.trustStore", "c:\\GLASSFISH\\config\\cacerts.jks");
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
I've also switched on debugging for ssl (Glassfish console, server, properties) javax.net.debug=ssl.
It works in a standalone test application (Java SE) but not in Glassfish.
UPDATE 2
Using the javax.net.debug=ssl and examining the log out put I can see that even-though I've loaded the certificate "everywhere" or if I point Glassfish to the java keystore, Glassfish is missing this certificate. The stand alone test app has it:
adding as trusted cert:
Subject: CN=avast! Web/Mail Shield Root, O=avast! Web/Mail Shield, OU=generated by avast! antivirus for SSL/TLS scanning
Issuer: CN=avast! Web/Mail Shield Root, O=avast! Web/Mail Shield, OU=generated by avast! antivirus for SSL/TLS scanning
Algorithm: RSA; Serial number: 0x14128fa09c50b64ba6d5c99875872673
Valid from Wed Feb 04 08:56:17 CAT 2015 until Sat Feb 01 08:56:17 CAT 2025
(Note the Serial number...)
It seems to be the certificate missing from Glassfish; because the stand alone test app finds it:
Found trusted certificate:
[
[
Version: V3
Subject: CN=avast! Web/Mail Shield Root, O=avast! Web/Mail Shield, OU=generated by avast! antivirus for SSL/TLS scanning
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: Sun RSA public key, 2048 bits
modulus: ---8<---
public exponent: 65537
Validity: [From: Wed Feb 04 08:56:17 CAT 2015, : Sat Feb 01 08:56:17 CAT 2025]
Issuer: CN=avast! Web/Mail Shield Root, O=avast! Web/Mail Shield, OU=generated by avast! antivirus for SSL/TLS scanning
SerialNumber: [ 14128fa0 9c50b64b a6d5c998 75872673]
...
(Look at the SerialNumber...)
Please help

Okey dokey! I've figured it out. Here is how my 5 day journey ended today, in brief...
First I dumped all the certificates from the Java keystore, as it was working using that keystore:
keytool -list -v -keystore c:\Progra~1\Java\jre7\lib\security\cacerts > allJavaCerts.txt
Then I dumped all the certificates from the Glassfish keystore, to see if the certificate was correctly imported:
keytool -list -v -keystore c:\WORKSP~1\GLASS\config\cacerts.jks > allGFCerts.txt
In the Java keystore list I notice that the mail server's certificate was issued by Avast... weird, right?
Issuer: CN=avast! Web/Mail Shield Root, O=avast! Web/Mail Shield, OU=generated by avast! antivirus for SSL/TLS scanning
And in the Java keystore list there is a certificate for Alias name: avastsslscannerroot but not in the Glassfish keystore list - Thank you Beyond Compare v3
So I exported the avastsslscannerroot certificate from the Java keystore and import it into the Glassfish keystore:
keytool -export -keystore c:\Progra~1\Java\jre7\lib\security\cacerts -alias avastsslscannerroot -file avastsslscannerroot.cer
keytool -import -alias avastsslscannerroot -file avastsslscannerroot.cer -keystore c:\WORKSP~1\GLASS\config\keystore.jks
keytool -import -alias avastsslscannerroot -file avastsslscannerroot.cer -keystore c:\WORKSP~1\GLASS\config\cacerts.jks
And now it works...
And then it didn't on the server... After some search I came across this:
mail.smtp.ssl.trust="*"
Property and it works for us as we are connection from our web server to our mail server...

It seems your local Virus Protection is Avast.
Your Problem is caused by its so called Active Protection Shield which intercepts SSL traffic and scans it for malicous content. In order to achieve this, Avast has to intercept communication between your Java-Program and the SMTPS-Server. For Details see this question or this question over at security.stackexchange.com
Problem:
Because the Avast-Certificate is (of course) not trusted by GlassFish and was not added to Glassfish at installation of Avast, the SSL connection can not be established
Possible Solutions:
Add the Avast-Certificate to GlassFishs list of valid certificates (thats what the questioner has done)
Disable this feature of Avast (Settings -> Active Protection -> E-Mail-Protection)

how to know the domain used in keystore/truststore?

I have self signed certificates for my https protocol based web application.but I want to know the domain mentioned in the keystore/truststore.
can any one help me to know it?

List certificates in keystore using following command:
keytool -list -v -keystore yourkeystorefile -storepass keystorepassword
Find your certificate and check the common name (CN) value in "Owner" tag. This is the domain name the certificate is created for.
Alternative domain names you may use are listed in optional SubjectAlternativeName section.

Before adding new certificates in keystore or truststore its good to see, count and verify already installed certificates. run following keytool command to get a list of certififcates from keystore:
javin#localhost:C/Program Files/Java/jdk1.6.0_26/jre/lib/security keytool -list -keystore cacerts
Enter keystore password: changeit
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 76 entries
digicertassuredidrootca, 07/01/2008, trustedCertEntry,
Certificate fingerprint (MD5): 87:CE:0B:7B:2A:0E:49:00:E1:58:71:9B:37:A8:93:72
trustcenterclass2caii, 07/01/2008, trustedCertEntry,
Certificate fingerprint (MD5): CE:78:33:5C:59:78:01:6E:18:EA:B9:36:A0:B9:2E:23
You see currently keystore "cacerts" holds 76 certificates.
Read more: http://javarevisited.blogspot.com/2012/03/add-list-certficates-java-keystore.html#ixzz39n3jfusy