I am lost on this one. We needed to update our SSL certificates so I got a new cert/pem from Comodo and updated Jira's user is with the new .keystore. Jira comes up and has a valid license that works just fine. Same for confluence
However, the application links between the two no longer work. When I did this same thing 2 years ago I had no problem with the application links afterward.
Also Just playing around with Curl from confluence to confluence I get this:
[root@confluence ~]# curl -v https://confluence.verdasys.com:8443/
* About to connect() to confluence.verdasys.com port 8443 (#0)
* Trying <ip removed for security>...
* Connected to confluence.verdasys.com (ip removed) port 8443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
* Server certificate:
* subject: CN=*.verdasys.com,OU=PremiumSSL Wildcard,OU=C Information Technology,O="DIGITAL GUARDIAN, INC.",STREET="860 Winte r Street, Suite 3",L=Waltham,ST=MA,postalCode=02451,C=US
* start date: Jan 18 00:00:00 2018 GMT
* expire date: Feb 20 23:59:59 2020 GMT
* common name: *.verdasys.com
* issuer: CN=COMODO RSA Organization Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
* NSS error -8179 (SEC_ERROR_UNKNOWN_ISSUER)
* Peer's Certificate issuer is not recognized.
* Closing connection 0
curl: (60) Peer's Certificate issuer is not recognized.
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
saying both it knows the issuers is COMODO and that the issuer is unrecognized?
I have one guess: The java version you currently use does not know the CA of Comodo, because it is outdated. And same with curl. Curl access the root certificates located in the file system installed by another package than curl. If they are out-of-date curl will fail.
In Ubuntu, for example, this package is called ca-certificates.
Thanks, but I already did an yum update ca-certificates to no avail. I am running CentOS 7. The thing is the last certificates we had were from comodo and they worked just fine. I believe it is something else. Possible I need to change the keystore somehow. Here is the contents of my keystore with the fingerprint not actually being XX's just did not show for security reasons.
1, Jan 19, 2018, PrivateKeyEntry,
Certificate fingerprint (SHA1): XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
I read somewhere that for Jira I need to export the private key into the ca of confluence and vise versa but I have no idea how to do that, and cannot seem to get any good results in google???
It's not the keystore but the truststore (same container but different parameter for the JVM). And yes, if both offer SSL connections you have to import the certs in each truststore, but only if the certificates cannot be verified by the JVM on its own. If you have an official certificate signed by a big player, then this truststore thing is not required.
Probably this article will help further: Running JIRA applications over SSL or HTTPS
Good stuff, I did that but afterwards do I need to reboot to enact the changes from config.sh? If so I have scheduled a reboot for Thursday, crossing fingers, as not only do the links work but also the cli does not as it will not work over non SSL
This is from a big player comodo.
I believe this is the solution:Follow our Connecting to SSL services to import the public certificate on the $JAVA_PATH/lib/security/cacerts file;
Find the java.home / java path through:
Then run these commands in Linux (the above for a windows app for those crazy enough to run on Windows)
# openssl s_client -connect jira.url.for.you:8443 < /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > public.crt
# keytool -import -alias jira -keystore <java.home above>/lib/security/cacerts -file public.crt
From both jira and confluence side (replace the --connect jira with a --connect confluence on the jira side)
Then reboot each system. I will let you know after I schedule another reboot this weekend if the above worked. It did work for the cli problem.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot