Self-signed certificates, Java, Hudson and JIRA

Question

I'm trying to set up the Hudson JIRA plugin. Our JIRA server is secured with an self-signed SSL certificate. I've inserted the certificate my web browser has stored using the keytool command, and gotten Hudson to find it. But now it complains:

java.security.cert.CertificateException: No subject alternative names present

The common name of the certificate is "Unknown", and I do not see any subject alternative names in the certificate

$ openssl x509 -in Unknown -text -noout
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 1214507595 (0x4863ea4b)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=US, ST=NJ, L=[Our town], O=[Our company], OU=[Our project], CN=Unknown
        Validity
            Not Before: Jun 26 19:13:15 2008 GMT
            Not After : May  5 19:13:15 2018 GMT
        Subject: C=US, ST=NJ, L=[Our town], O=[Our company], OU=[Our project], CN=Unknown
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                [omitted]
    Signature Algorithm: md5WithRSAEncryption
        [omitted]

(Identifying info redacted and noted in brackets.)

Is there a way to attach a subject alternate name to this certificate? Or is there some other way? Or am I forced to hack the Hudson Jira plugin?

Solution 1

The hostname used to access your Jira server (e.g. jira.acme.com in https://jira.acme.com/) must either match one of the CN fields of the subject name or, when it doesn't, one of the Subject Alternative Name of the cert.

This is detailed in the RFC 2818:

In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.

In your case, Java is complaining because neither the CN ("Unknown") nor a Subject Alternative Name (since you have none) did match the hostname of your Jira server.

So, either generate a certificate with the appropriate CN, for example using keytool:

To create a keypair and self-signed certificate

$ keytool -genkey -alias jira_acme_com -keyalg RSA -keysize 2048 -validity 365 -keystore jira_acme_com.jks
Enter keystore password:  
Re-enter new password: 
What is your first and last name?
  [Unknown]:  jira.acme.com
What is the name of your organizational unit?
  [Unknown]:  Our project
What is the name of your organization?
  [Unknown]:  Our company
What is the name of your City or Locality?
  [Unknown]:  Our town
What is the name of your State or Province?
  [Unknown]:  NJ
What is the two-letter country code for this unit?
  [Unknown]:  US
Is CN=jira.acme.com, OU=Our project, O=Our company, L=Our town, ST=NJ, C=US correct?
  [no]:  y

Enter key password for 
        (RETURN if same as keystore password): 

To view the personal information

$ keytool -list -v -keystore jira_acme_com.jks 
Enter keystore password:  

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: jira_acme_com
Creation date: Sep 4, 2010
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=jira.acme.com, OU=Our project, O=Our company, L=Our town, ST=NJ, C=US
Issuer: CN=jira.acme.com, OU=Our project, O=Our company, L=Our town, ST=NJ, C=US
Serial number: 4c81e9a9
Valid from: Sat Sep 04 10:39:37 CEST 2010 until: Sun Sep 04 10:39:37 CEST 2011
Certificate fingerprints:
     MD5:  15:6A:E3:14:E2:78:F4:95:41:E6:33:C9:F8:8B:64:23
     SHA1: CD:A6:9A:84:18:E8:62:50:2C:DC:2F:89:22:F6:BA:E9:1A:63:F6:C6
     Signature algorithm name: SHA1withRSA
     Version: 3

And setup Tomcat to use the keystore.

Of, if you want to create a multihomed certificate, you'll have to use OpenSSL (keytool cannot add X509 extensions such as Subject Alternative Name). These links are excellent resources:

• Creating an SSL Certificate with Multiple Hostnames
• OpenSSL - Community Ubuntu Documentation

Update: Given that you can't change the certificate (you really should have mentioned that), a temporary solution could be to change the local /etc/hosts file of the required machines to resolve Unknown to the real IP of the machine.

123.123.123.123    Unknown

So that you could access https://Unknown/ from these machines. But obviously, this is more a dirty hack than a real solution and doesn't scale.

Contacting the admins to get a real "good" certificate is still the real good solution.

Resources

• A few frequently used SSL commands (using openssl or keytool)
• Creating an SSL Certificate with Multiple Hostnames
• OpenSSL - Community Ubuntu Documentation

References

• RFC 2818
• keytool - Key and Certificate Management Tool
• Apache Tomcat 6.0 - SSL Configuration HOW-TO

Solution 2

If I'm not mistaken, SSL requires that the common name of the certificate contain the hostname that you're attempting to connect to, that way the client side can validate that the certificate is not just trusted in general, but trusted for the location.

I'm assuming you're generating the certificate with OpenSSL. Is there a reason you're not setting the cn=[yourserver]?

It may be that when it cannot find the proper hostname in the common name, that the plug-in attempts to look for it in a subject alt name, and when that fails because there is no subjectAltName, you're getting a bad error message.

Anyway, if you're using this for multiple sites, you need to have the hostnames in the subjectAltName. I've found a site that documents how to create your self-signed cert properly.

http://library.linode.com/ssl-guides/subject-alt-name-ssl

Hope this helps.

Comments

[Anuj Singh]

I am just a basic user. The certificates, and the JIRA setup was done by the sysadmins. I do not know why they did not set the name in the certificate.

[Anuj Singh]

The browser warnings are prompts for user acceptance of the self-signed certificate, and once permanently stored, do not arise again. I'm more tempted by the second option. I do not have root on my machine, but my co-workers do. I can change this locally and then use this to demonstrate Hudson to superiors and then if I get even weak approval, get the sysadmins to change the certificate. (I realize it's really clumsy, and was hoping for a solution that would just affect Hudson itself, and not my entire system.)

[Anuj Singh]

First, I do not have access to change the certificate I see from the server. Second, JIRA server does not have a hostname (at least I've never used one) just an IP. (That probably doesn't matter to what you said, but just in case.) Thanks for all the links though.

[Shawn D.]

If there is no hostname or IP address in the certificate, it is the equivalent of a valid passport with no name. The certificate is valid, but there's no way to tie it to the host it's deployed on.

[Devanshu Mevada]

@AFoglia Well, why didn't you mention that in the question? :S Anyway, you should really setup a valid cert (with either a real hostname - the machine does have one - or the IP address in the SubjectAltNames extension). If this is not under your control, then your admins must do it. Contact them.