Error opening https url: keyCertSign bit not set

Question

Error opening https url: keyCertSign bit not set

I call the https remote URL with the following code:

def inputStream = new URL("https://somewebsite.com").openStream()

This works fine on my local machine, but when I deploy the server, I get the following exception:

 java.security.cert.CertPathValidatorException: CA key usage check failed: keyCertSign bit is not set

What is the reason for this error, and what could explain its operation on one machine, and not another?

UPDATE

I am running an Ubuntu server in production and development on a local Mac. The site I'm trying to access (call peopleware.com on it) has the following certificate information:

AddTrust External Root CA
UTN-USERFirst-Equipment
peopleware.com

I tried saving the .cer files from my browser and installing them in the keystore in / etc / ssl / certs / java / castore

+6

java ssl groovy

Mike sickler Apr 22 '12 at 12:34

source share

1 answer

Bruno · Answer 1 · 2012-04-24T18:10:52+0000

I assume that you are talking about this certificate from UTN-USERFirst-Hardware:

In a readable version:

 Version: 3 (0x2) Serial Number: 44:be:0c:8b:50:00:24:b4:11:d3:36:2a:fe:65:0a:fd Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Hardware Validity Not Before: Jul 9 18:10:42 1999 GMT Not After : Jul 9 18:19:22 2019 GMT Subject: C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Hardware Subject Public Key Info: [...] X509v3 extensions: X509v3 Key Usage: Digital Signature, Non Repudiation, Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Key Identifier: A1:72:5F:26:1B:28:98:43:95:5D:07:37:D5:85:96:9D:4B:D2:C3:45 X509v3 CRL Distribution Points: Full Name: URI:http://crl.usertrust.com/UTN-USERFirst-Hardware.crl X509v3 Extended Key Usage: TLS Web Server Authentication, IPSec End System, IPSec Tunnel, IPSec User

Essentially, we have a CA certificate with the X509v3 Key Usage and X509v3 Extended Key Usage .

However, RFC 3280 says the following about extending an extension of an extended key :

In the general case, this extension will be displayed only in the final certificate object.

This does not work well for a CA certificate, but later in the same section the following is said:

If the certificate contains both a key usage extension and an extended key use extension, then both extensions MUST be processed independently, and the certificate MUST be used only for the purpose of both extensions. If there is no purpose with both extensions, then the certificate SHOULD NOT be used for any purpose.

The only extended key usage extension in this certificate, which is in this RFC, is TLS web server authentication:

  id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } -- TLS WWW server authentication -- Key usage bits that may be consistent: digitalSignature, -- keyEncipherment or keyAgreement

Of course, this is not consistent with keyCertSign , which is according to RFC 3280 (and RFC 5280). (I also doubt that any IPSec extensions are compatible with keyCertSign ). This makes this certificate useless for issuing certificates (not very useful for a CA certificate).

I would like to contact the website using this certificate to ask them to contact their CA (UTN-USERFirst-Hardware, apparently Comodo) and ask them to fix it. I must say that this does not look good based on people who make their money on the back of these RFCs.

Of course, this may take some time and will not solve your immediate problem.

I think I saw this subject DN (UTN-USERFirst-Hardware) in other CA intermediate certificates, so one of them might not be the one you are using.

What you could do (provided that you yourself can verify the server certificate manually, despite these problems) is to use SSLContext and TrustManager , specially limited to use this certificate itself, for this connection. This can prevent the certification path algorithm from trying to find the issuer certificate and get into this problem.

EDIT:

Here is more detailed information about this workaround (which should still keep your connection safe).

Connect to Firefox on this website.
Click on the blue / green bar and select "More information ..."
Security → View Certificate → Details
Select a server certificate from the list above and select "Export ..."
Same thing in the PEM file.

Use keytool to create a new keystore (select to trust this certificate and choose a reasonable password):

 keytool -importcert -keystore example.jks -file example.pem

Then use this Java code, which should not be too complicated to port to Groovy:

 TrustManagerFactory tmf = TrustManagerFactory .getInstance(TrustManagerFactory.getDefaultAlgorithm()); KeyStore ks = KeyStore.getInstance("JKS"); FileInputStream fis = new FileInputStream("/.../example.jks"); ks.load(fis, null); // or ks.load(fis, "thepassword".toCharArray()); fis.close(); tmf.init(ks); SSLContext sslContext = SSLContext.getInstance("TLS"); sslContext.init(null, tmf.getTrustManagers(), null); URL url = new URL("https://somewebsite.com"); HttpsURLConnection conn = (HttpsURLConnection) url.openConnection(); conn.setSSLSocketFactory(sslContext.getSocketFactory()); InputStream is = conn.getInputStream();

Error opening https url: keyCertSign bit not set

More articles: