Reverse proxies are a bit easier to set up and offer a little more performance than serving TLS from Tomcat (Jira's application server) directly. I would recommend that in case #2 - serving Jira over HTTPS, that you instead look at using a reverse proxy such as nginx or Apache to terminate the TLS connection between the server and the client's browser. Instructions for that are in this document - Running Jira applications over SSL or HTTPS . In this case, you'll need to import the public and private certificates into the keystore. You are serving HTTPS/TLS from Jira directly - your users connect to Jira over HTTPS and their connection is not terminated at a reverse proxy.In this case, you'll import the public certificate using these instructions. You want Jira to connect to a server that uses a certificate signed by an internal authority (example: LDAPS, Exchange, etc - most common in Windows environments), a public authority that isn't in the default Java keystore, or a self-signed certificate.You'd need to import certificates in these circumstances: By default, the keystore holds certificates for most public Certificate Authorities (GoDaddy, Verisign, Comodo, GeoTrust, etc). When changing JDKs, you'll need to consider what certificates you've already imported to your keystore. We also bundle AdoptOpenJDK with our installers (Jira 8.3 and above), so installations/upgrades to versions 8.3 or above may already be using AdoptOpenJDK. Jira has supported OpenJDK for a bit now - 7.13 and all versions of Jira 8 support OpenJDK.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |