JIRA Server Android Application

Question

Hi,

Recently I upgraded my JIRA Server to version 8.0.2. We're using JIRA behind the reverse proxy of nginx with SSL. Unfortunately, we don't have signed certificate, therefore we are using with self-signed certificate. We have no problems while using our JIRA with browser. However, if I try to connect using new JIRA Server Android Application, I got an error says "Can't get a secure connection".

As stated in the link [https://confluence.atlassian.com/jirakb/can-t-get-a-secure-connection-error-on-jira-server-mobile-app-954244746.html], I added my self-signed certificate to my device's trusted certificates. The first following screenshot taken from Firefox Browser, and the second one is from my Android Phone. As you can see, these are the same certificate.

I also export my certificate to JIRA JRE  as described in here [https://confluence.atlassian.com/display/APPLINKS060/SSL+and+application+link+troubleshooting+guide]

Also, my self-signed certificate has;

X509v3 extensions:
  X509v3 Basic Constraints:
    CA:TRUE

Which I can see if I execute the following command;

openssl x509 -in gohm.crt -text -noout

X509v3 extensions:
X509v3 Subject Key Identifier:
12:96:35:D0:BE:E6:91:70:F3:0F:70:38:E3:93:60:10:3D:41:9C:C4
X509v3 Authority Key Identifier:
keyid:12:96:35:D0:BE:E6:91:70:F3:0F:70:38:E3:93:60:10:3D:41:9C:C4

X509v3 Basic Constraints: critical
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption

At this point, I would like to ask what might cause the connection problem? We are hosting our JIRA in our private server and it has ufw (uncomplicated firewall). Only required incoming ports enabled. Is there any special port for JIRA Server mobile app to communicate JIRA Server?

Best Regards,

Said Ucar.

Andy Heinzer · Answer

It's not necessary that you have done something wrong.  Instead, I think that we're just missing the intermediate certificate to make this work on a mobile client.   If this was a signed cert from a root CA, we wouldn't have to worry about this, but since you're using a self-signed cert, and the mobile clients can't retrieve this intermediate CA cert.

We can see this in the command:

openssl s_client -connect jira.gohm.com.tr:443
CONNECTED(00000005)
depth=0 C = TR, O = GOHM Electronics and Software, CN = *.gohm.com.tr
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = TR, O = GOHM Electronics and Software, CN = *.gohm.com.tr
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = TR, O = GOHM Electronics and Software, CN = *.gohm.com.tr
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=TR/O=GOHM Electronics and Software/CN=*.gohm.com.tr
i:/C=TR/O=GOHM Electronics and Software Ltd./CN=*.gohm.com.tr
---

These two certs look very similar, but technically they are in a chain.  With the latter having the 'Ltd.' at the end.   Your mobile clients aren't able to retrieve the first certificate.  That is the cause of the problem here.

The guide in https://developer.android.com/training/articles/security-ssl#MissingCa explains this further.  Following the steps there could help.  Essentially you would need to make sure that your site/proxy hosting SSL is also serving up this intermediate certificate in addition to main certificate.  Many times that site does not actually have this other root certificate to serve up to end users.

So that is one way to try to troubleshoot this.

However instead of following that path, I am interested to see if perhaps there is another solution possible.   It would be significantly better if you could use a CA signed certificate here instead of a self-signed one.  Have you seen the website https://letsencrypt.org/ ?  It's a website that can offer you the ability to obtain a free certificate from a CA.

I think that this approach could be a better way to make this work for both desktop and mobile clients to Jira.

msaiducar · Answer

Hi @Andy Heinzer ,

Thank you about your effort. Actually, I'm not good at the openssl or ssl certification details. I used the commands below to create my self signed certificate. If you know what part of it was wrong, i would appreciate.

This is my openssl.cnf

[req]
default_bits = 2048
encrypt_key  = no # Change to encrypt the private key using des3 or similar
default_md   = sha256
prompt       = no
utf8         = yes
distinguished_name = req_distinguished_name
req_extensions = v3_req
[req_distinguished_name]
C  = TR
O  = GOHM Electronics and Software
CN = *.gohm.com.tr
[v3_req]
basicConstraints     = CA:TRUE
subjectKeyIdentifier = hash
keyUsage             = digitalSignature, keyEncipherment
extendedKeyUsage     = clientAuth, serverAuth

This is how I create CA certificate

openssl req \
  -new \
  -newkey rsa:2048 \
  -days 3650 \
  -nodes \
  -x509 \
  -subj "/C=TR/O=GOHM Electronics and Software Ltd./CN=*.gohm.com.tr" \
  -keyout "${DIR}/ca.key" \
  -out "${DIR}/ca.crt"

This is how I create private key

openssl genrsa -out "${DIR}/gohm.key" 2048

This is how I generate CSR

openssl req \
  -new -key "${DIR}/gohm.key" \
  -out "${DIR}/gohm.csr" \
  -config "${DIR}/openssl.cnf"

This is how I signed my pri key

openssl x509 \
  -req \
  -days 3650 \
  -in "${DIR}/gohm.csr" \
  -CA "${DIR}/ca.crt" \
  -CAkey "${DIR}/ca.key" \
  -CAcreateserial \
  -extensions v3_req \
  -extfile "${DIR}/openssl.cnf" \
  -out "${DIR}/gohm.crt"

Which part exactly am I doing wrong here?

Andy Heinzer · Answer

Hi Mustafa, Thanks for this information. From looking at this and discussing with my colleagues, I believe that your clients are Missing the intermediate certificate authority From that post: The third case of SSLHandshakeException occurs due to a missing intermediate CA. Most public CAs don't sign server certificates directly. Instead, they use their main CA certificate, referred to as the root CA, to sign intermediate CAs. They do this so the root CA can be stored offline to reduce risk of compromise. However, operating systems like Android typically trust only root CAs directly, which leaves a short gap of trust between the server certificate—signed by the intermediate CA—and the certificate verifier, which knows the root CA. To solve this, the server doesn't send the client only it's certificate during the SSL handshake, but a chain of certificates from the server CA through any intermediates necessary to reach a trusted root CA. I would recommend trying to walk through that section of the guide here. It does explain some additional diagnosis steps to follow to make sure this is the case here. It also offers two different approaches to try to solve this issue. I hope this helps. Andy