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?
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
:
$ 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):
$ 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:
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With