Hi Archana,
Sorry to hear about the frustration here. However the title of this post and content in the description appear to be dealing with two very different problems with configuring a mailbox for Jira to use.
I'd like to address Shared Mailbox aspects mentioned in the title first. Please see our KB on IMAP fails with A3 BAD User is authenticated but not connected error in Jira server integrated with Office365. It highlights a very common problem that Jira will not yet support the use of a shared mailbox over IMAP at this time. That said there is a workaround here that can still offer a means to use that mailbox, albeit using a different protocol. The solution there is to instead use a POP3 protocol instead of IMAP, and have the username reference the sharedmailbox alias like so:
Protocol: SECURE_POP
Host: outlook.office365.com
Port: 995
Username: licenseduser@mydomain.com\sharedmailboxalias
Password: (licensed user password)
That is at least one way that we know Jira server and data center deployments can connect to such mailboxes.
As for the problem you primarily are writing about, the TLS/SSL connection problem:
We have see the specific error you mentioned before, often enough that we create a knowledge base article about it in SSL connections fail from Jira server to external systems.
In short that KB confirms that Jira's JVM truststore does not yet see the needed certificate to be able to connect to that service. While that guide does state the resolution is to follow the Connecting to SSL services guide and I agree we should eventually follow that to the letter, in your case before you do that the first steps should be instead to install a JAVA JRE/JDK separately on the operating system of each node rather than trying to use the bundled JRE. This could be an Oracle Java or possibly an OpenJDK depending on which is supported per the supported platforms for the version of Jira you have.
I know you mentioned that you configured the JAVA_HOME variable to point at the bundled Java deployment included with Jira, but I'm not a fan of this approach. Mostly because we know that Jira upgrades have the potential to overwrite/change data in the $JIRAHOME/ and $JIRAINSTALL/ directories. By installing Java separately, in its own directory and setting up JAVA_HOME to use that JVM, we can make Java and its truststore far more resilient to upgrades of Jira itself. Otherwise every time you upgrade Jira you will potentially need to add back all SSL/TLS certificates needed to connect to secured sites all over again (and for each node).
The more difficult aspect about doing that here is that since you are on a data center deployment, you would have to repeat these steps for each node in the cluster. That could be a frustrating and confusing additional factor here with data center. Out of the box with data center, it's not always clear which of the nodes in a data center cluster will be making the outbound call to the mail server to retrieve that data, so each node has to be setup with the correct certificates so any one of them can successfully make this connection.
I hope this helps to clarify things a bit. Please let me know if you have any questions or concerns about this approach.
Cheers,
Andy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.