On 4.4.2014 5:23, Toby Lazar wrote:
I've run my client program with the -Djavax.net.debug=all option. First it
listed out all of the trusted authorities. Mine is GoDaddy and this is the
record:
That one is not the issuer of your certificate. GoDaddy has many issuing
certificates. The GoDaddy certificate the client trusts expires in 2034
whereas your issuer certificates expire in 2031/2037. Also, the DNs are
different. Better to identify the trusted certificate by serial number and
subject key identifier.
+1.
It seems to be known issue with GoDaddy G2 certificate:
http://stackoverflow.com/questions/18746565/godaddy-ssl-cert-not-working-with-java
"[GoDaddy] have 2 CA servers, one called Class 2 CA and the other called
G2 CA. Their Class 2 CA signs all SHA-1 certificates, while the G2 CA
signs all their SHA-2 certificates. This is where the problem lies -
GoDaddy has not added their newer G2 CA server to the default java
truststore - causing default java installations to not trust it's
authority, and hence, does not trust your chained certificate. The
work-around until GoDaddy adds the G2 CA server to the default
truststore is to simply rekey your cert using SHA-1 as-to get a cert
signed by the Class 2 CA server. Rekeying is free for GoDaddy customers
until your cert expires (obviously)."
FTR, GoDaddy or any other CA can't just "add" certificate to Java root
certificates, but it must apply at Oracle for inclusion.
This is what I think is the relevant part:
[3]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:false
PathLen:2147483647
]
It just says that server certificate you have cannot be used to sign
other certificates, nothing else. That is irrelevant for you.
-Ognjen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
