JIRA Mail initiates TLSv1 connection only
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Outdated- superseded by How to modify the TLS version Jira uses when connecting as a client
Problem
JIRA Mail initiates Transport Layer Security (TLS) connection to Mail server, this includes IMAPS/POP3S or SMTPS protocols. It's TLSv1 connection and it's doesn't initiate TLSv1.1 or TLSv1.2. Taking into account that TLSv1 doesn't offer all the newest encryption cyphers, it's preferable to switch to TLSv1.2 protocol
Diagnosis
Environment
JIRA with configured Incoming and/or Outgoing mail.
Diagnostic Steps
Enable SSL debug option and check logs:
1-Djavax.net.debug=ssl:handshake:verboseYou can see JIRA mail initiating TLSv1 connection:
1 2 3 4*** ClientHello, TLSv1 http-bio-8080-exec-25 , WRITE: TLSv1 Handshake, length = 160 http-bio-8080-exec-25 , READ: TLSv1 Handshake, length = 91 *** ServerHello, TLSv1in some cases connection can fail due to parametr mismatch:
1 2 3 4 5 6*** ClientHello, TLSv1 atlassian-scheduler-quartz1.clustered_Worker-2, WRITE: TLSv1 Handshake, length = 163 atlassian-scheduler-quartz1.clustered_Worker-2, READ: SSLv3 Alert, length = 2 atlassian-scheduler-quartz1.clustered_Worker-2, RECV TLSv1.2 ALERT: fatal, illegal_parameter atlassian-scheduler-quartz1.clustered_Worker-2, called closeSocket() atlassian-scheduler-quartz1.clustered_Worker-2, handling exception: javax.net.ssl.SSLException: Received fatal alert: illegal_parameteror fail due to No negotiable cipher suite:
1 2 3 4*** ClientHello, TLSv1 atlassian-scheduler-quartz1.clustered_Worker-1, handling exception: javax.net.ssl.SSLHandshakeException: No negotiable cipher suite atlassian-scheduler-quartz1.clustered_Worker-1, SEND TLSv1.2 ALERT: fatal, description = handshake_failure atlassian-scheduler-quartz1.clustered_Worker-1, WRITE: TLSv1.2 Alert, length = 2
Cause
JIRA for Incoming Mail (atlassian.mail.incoming.mailfetcherservice) and similar for outgoing uses javax.mail 1.4.5. This library uses it's own defaults for for TLS: 'sslsocket.setEnabledProtocols(newString[] {"TLSv1"});' and not global Java one.
Solution
Resolution
You can override Java mail setting and set TLS to specific version, please add following JVM option to the startup parameters (see Setting Properties and Options on startup) :
1
2
3
-Dmail.imap.ssl.protocols="TLSv1.2"
-Dmail.smtp.ssl.protocols="TLSv1.2"
-Dmail.pop3.ssl.protocols="TLSv1.2"See Package-summary.html#mail.imap.ssl.protocols for more details. Similar setting for SMTP: Smtp - package-summary
This should change TLS behaviour:
1
2
3
4
*** ClientHello, TLSv1.2
http-bio-8080-exec-25 , WRITE: TLSv1.2 Handshake, length = 216
http-bio-8080-exec-25 , READ: TLSv1.2 Handshake, length = 91
*** ServerHello, TLSv1.2Was this helpful?