We are running Atlassian Servers which use JAVA Tomcat for cacert truststore
I have not tried anything yet as I have been reading through the documentation I’m not sure what path to take.
We have Fedora 24 server running Atlassian JIRA, so I think I would use certbot to do the job.
Has anyone used certbot with a Atlassian tomcat environment and provide me with an idea of what I should do?
You mention the cacert truststore. Is your goal here to have the servers use an SSL server certificate from Let’s Encrypt (so web browsers can be used to access the JIRA) ? Or to have the JIRA be able to achieve trust in some other server, which has certificates issued by Let’s Encrypt, for example a version control server or chat server of some sort ? Or both?
The latter should work “out of the box” with a new enough Java, but otherwise it will usually make sense to add IdenTrust’s CA to the system-wide Java trusted CA store, the same thing that Oracle have done in latest Java and there are existing guides on how to do that I think.
The rest of this text assumes you need the former, ie to have a JIRA server with a valid SSL certificate.
Firstly, be sure your JIRA server has a Fully Qualified Domain Name from the Internet e.g. “jira.example.com” not “jiraserver” or “jiraserver.contoso.corp”. Without that, Let’s Encrypt is not permitted to issue you a certificate. If the JIRA server isn’t accessible from the public Internet (e.g. it’s behind a firewall prohibiting all inbound traffic), but does have an Internet FQDN, you can get certificates but may need to do a bit more work, since you won’t be able to simply run certbot from the Jira server and should research further to ensure you can achieve your goal.
Once you can get a certificate, a lot of http://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html probably applies (assuming you have Tomcat 8.5.x), although the “Quick Start” instructions can be ignored unless you first want to see SSL-enabled Tomcat working at all on your system without the Let’s Encrypt valid certificate.
Note that there are separate instructions depending on whether you end up with the Apache Portable Runtime (APR) or the native Java stuff making this go.
The APR stuff works a lot like Apache’s web server, and so the settings for certbot generated certificates will be correspondingly simple, you’ll need the server.xml or equivalent to set
SSLCertificateFile="/etc/letsencrypt/live/example.com/fullchain.pem"
SSLCertificateKeyFile="/etc/letsencrypt/live/example.com/privkey.pem"
except that obviously the DNS name of your JIRA server needs to go where it says example.com
For native Java, you need to create either a PKCS12 or Java Keystore from those two files, and you will need to redo this step every time certbot renews your Let’s Encrypt certificate (every 2-3 months) so you should develop a script to do it and tell certbot with “hooks” to run that script after renewal.
Thanks for the info. Yes ultimate Both.
Currently have:
-a jira.jks file that has a self-signed cert in it
-this jira.cert is exported and imported into the java truststore so that JIRA can talk to itself and Bitbucket (which is on the server as well).
JIRA uses the truststore to talk to itself using the a base URL var, which is the internet FQDN (yes we have one).
So I hopeful that this will work. It appears that I have to do two things.
I could automate this in CRON easily enough. I think I’m getting the big picture in my head.
So down to the nitty gritty…
1 What is my certbot command to create the certs?
2 What is my certbot command to renew?
I've been reading all the documentation and I'm not sure what the command would be to get a cert issued. I've tried the following:
certbot certonly --manual --test-cert -m sys.admin@example.com -d example.com -d jira.example.com -d confluence.example.com -d bitbucket.example.com
This I accepted the TOS and then accepted the IP association (this is on a different system then the production web services). Then certbot instructs me to do (on the production system):
mkdir -p /tmp/certbot/public_html/.well-known/acme-challenge
cd /tmp/certbot/public_html
printf "%s" <removed...> > .well-known/acme-challenge/<removed...>
# run only once per server:
$(command -v python2 || command -v python2.7 || command -v python2.6) -c \
"import BaseHTTPServer, SimpleHTTPServer; \
s = BaseHTTPServer.HTTPServer(('', 80), SimpleHTTPServer.SimpleHTTPRequestHandler); \
s.serve_forever()"
Which I cancelled out of as we don't have Firewall rules to deal with port 80 routing. So if I setup the port 80 rules and then run the above certbot command again and then run the temp server commands, I guess I will get a cert that I will be able to manually put into place.
I found a couple google hits on this topic but all examples are so different I'm not sure what to do. So I decided to start down the above path and see where it takes me.
Yes. This looks OK. A few ideas:
That acme.sh shell script might make it practical to run everything on the production server (doesn’t need Python or anything like that but does need the openssl command, and a shell) so it could all be a bit more automatic. If you end up happy with certbot’s manual mode it’s fine, just the acme.sh might be easier.
Also the root certificate you’ll most likely want to trust to make these certificate work in anything but the latest Java is the one from IdenTrust (who cross sign for Let’s Encrypt). If you’ve got a brand new Java it’ll already trust this, but most people’s production systems aren’t running bleeding edge Java, I know mine don’t.
https://www.identrust.com/certificates/trustid/root-download-x3.html
We are running Java 8u102 which I think is the latest. Thanks for the IdenTrust info…
I’ll take a look at the acme.sh script. So are you saying that the script doesn’t do the temp web server stuff?
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.