Login/Register
Self-signed certificates, Java, Hudson and JIRA
Asked Answered
javassl-certificatejirahudson-plugins
M

3

16

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?

Matronymic answered 1/9, 2010 at 23:18 Comment(1)
The response below are good, but I'd like to clarify: I do not have access to modify the JIRA server, or the certificate it uses. I do obviously have access to the certificate I store in Java's keystore. I was hoping to modify that copy of the certificate I downloaded to insert the appropriate subject alternate name where Java would look for them. – Matronymic
R
23

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:

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

References

Rager answered 4/9, 2010 at 7:26 Comment(3)
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. – Matronymic
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. – Coze
@Matronymic 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. – Rager
C
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.

Coze answered 4/9, 2010 at 4:3 Comment(1)
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. – Matronymic
A
0

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.
Aghast answered 9/9, 2010 at 12:28 Comment(1)
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.) – Matronymic

© 2022 - 2024 — McMap. All rights reserved.