JIRA Mail initiates TLSv1 connection only

Still need help?

The Atlassian Community is here for you.

Ask the community


Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.

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



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: 

    -Djavax.net.debug=ssl:handshake:verbose

    You can see JIRA mail initiating TLSv1 connection:

    *** ClientHello, TLSv1
    http-bio-8080-exec-25 , WRITE: TLSv1 Handshake, length = 160
    http-bio-8080-exec-25 , READ: TLSv1 Handshake, length = 91
    *** ServerHello, TLSv1

    in some cases connection can fail due to parametr mismatch: 

    *** 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_parameter

    or fail due to No negotiable cipher suite:

    *** 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(new String[] {"TLSv1"});' and not global Java one. 

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) :

-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:

*** 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.2

Last modified on Aug 30, 2022

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.