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?

Answer 1

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.

Answer 2

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

Answer 3

There are several possible solutions, each with its own set of pains.

• Generate a new certificate for JIRA, this time specifying a CN when generating the secret key-pair for the certficate.

  I cannot see why a new certificate cannot be generated; I'm pretty sure that other client to the JIRA server are also encountering some issues, especially warnings from browsers, for the described certificate. All clients (and client applications) must therefore be re-tested, but this is not a pain, if the self-signed certificate has been issued by a local CA that is trusted by all clients.

• Edit the DNS entries to ensure that the lookup to 'Unknown' from the Hudson server, points to the server where JIRA is installed [I did remind someone that there are pains associated with some of the solutions :-) ]. This ensures that the value of the CN stored in the certificate matches with the hostname - you'll need to configure Hudson to use a URL like http://Unknown/..... And oh, use this only if you're in a really tight spot; you don't want to be explaining why you did this.