Maileater certificate errors with Office 365 appearing without warning
search cancel

Maileater certificate errors with Office 365 appearing without warning


Article ID: 198751


Updated On:


CA Service Desk Manager CA Service Management - Service Desk Manager


Maileater has been connecting to Office 365/Outlook.Com for some time now, but as of Jul or Aug, 2020, experiencing errors in the maileater_nxd.log

2020-09-01 13:01:01:883 ERROR  [ForkJoinPool-1-worker-1] c.c.S.m.c.JavaMailIMAPClient - Failed to connect to the Store.
javax.mail.MessagingException: PKIX path building failed: No issuer certificate for certificate in certification path found.

Also seeing: 

2020-09-03 09:20:07:638 ERROR  [ForkJoinPool-1-worker-3] c.c.S.m.c.JavaMailIMAPClient - Failed to make connection with STARTTLS to server, port 993, trying SSL connection
2020-09-03 09:20:08:393 ERROR  [ForkJoinPool-1-worker-3] c.c.S.m.c.JavaMailIMAPClient - Failed to connect to the Store.
javax.mail.MessagingException: PKIX path building failed: unable to find valid certification path to requested target


Release : 17.1 and higher



A new root certificate was issued for SSL connections to Microsoft via Office 365 or Outlook.Com.  Any existing certificates will no longer be valid and need to be replaced.


The recommended approach to obtain the root CA is to use OpenSSL.  OpenSSL does not need to be installed on the same server as Service Desk.  One can install OpenSSL on on any computer with internet access to access the Outlook Mail server on the Internet using OpenSSL and acquire the Root CA

The reason why OpenSSL is advised is that one can run a specific command that accesses the given Office 365 server being used for IMAP connections to look up the necessary Root CA Certificate specification which can change per Microsoft's specifications.

Download OpenSSL from the following location:

Extract the "" file and then locate/run the following command in command prompt:

openssl s_client -starttls imap -connect -showcerts -debug

Another variation you can try if you are using Direct SSL (port 993) or for POP (port 995):

openssl s_client -connect -showcerts -debug
openssl s_client -connect -showcerts -debug

Note:  The same Root CA should be generated regardless of which of the above three OpenSSL commands are tried here.  They are supplied here to prove one can use OpenSSL to obtain the Root CA block AND that it is the same Root CA when connecting via POP (port 995), IMAP/StartTLS (port 143) or IMAP/Direct SSL (Port 993)

openssl.exe is located in the "openssl-1.0.2j-fips-x86_64\OpenSSL\bin" location (where you would have unzipped "". 

Look for a text line that reads "Root CA". This will most likely be "DigiCert Global Root CA"

This line will be where you can locate the root certificate which you can then copy into a cer file.

Copy all of the content between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----".  Make sure to include the "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" header/footer and include a single carriage return at the end of the file.  You will be writing/saving the "cer" file in Notepad, ie:  "outlook_root.cer".  

The certificate file that is attached to this tech doc is NOT the same as the content being pulled from openssl, but can be viewed as an example of the content format that should be followed when creating the given cer file.

The reason that this approach is recommended is that Microsoft may change their certificate requirements at will and the above will provide a snapshot into their latest certificate file usage.

To install the new certificate:

  1.   Create a "outlook_root.cer" file in Notepad and paste the contents of the given certificate into the file, then save the file to a given location on your SDM Server.  In this case, we will use "C:\certs".

    Note:  Make sure you are using a new certificate file name.  Do not use an existing certificate file as the keystore will reject the updated certificate due to a filename conflict.

  2.   Go into Maileater settings.  Login to SDM as an Administrative user.  Navigate to the Administration tab, then select Email -> Mailboxes, and select the specific Mailbox that is connecting to Outlook/Office 365.

  3.   Edit the Mailbox settings.  Under "CA Certificate Path" change the entry to the above certificate file and path:

  4.   Save the above Mailbox setting.  You may also need to update the Mail Notifications in Options Manager with the location of the new certificate file if Office 365 is also used here (option:  mail_ca_cert_path).

  5.  Recycle SDM Services to have the changes take effect. 

    Alternatively, instead of recycling SDM, you may also try bouncing maileater and mail processes by running:

    pdm_bounce maileater_nxd
    pdm_bounce mail_nxd

You may also copy the above certificate file to any other locations within your SDM environment as needed, such as a Standby or App Server for Advance Availability.

In addition, please make sure your Outlook/Office 365 hostname and port configurations are correct.  There have been some reports of accesses to "" or" being affected.  The specific instructions to verify your IMAP/POP/SMTP Server configurations are available here:

Additional Information

A way to confirm that you are importing a root certificate file is to use the keytool.exe command (supplied with all JRE implementations):

An example command you can run:

"C:\Program Files (x86)\Java\jre1.8.0_261\bin\keytool.exe" -printcert -v -file test-new.cer

The "test-new.cer" file is a text based file that contains a certificate block.  Running keytool on the root certificate will result in text similar to this output:

Owner: CN=DigiCert Cloud Services CA-1, O=DigiCert Inc, C=US
Issuer: CN=DigiCert Global Root CA,, O=DigiCert Inc, C=US


We do not recommend placing multiple certificate entries in the same certificate file, including appending the certificate content into an existing certificate file.

To verify that the certificate is present:

  • Go to a command prompt on a running SDM Server where you copied the certificate file.

  • Run "nxcd bin" to access the SDM install directory's bin directory.

  • Run the command "pdm_perl -list -v"

You should see a result such as:

Alias name: outlook_root.cer
Creation date: Sep 3, 2020
Entry type: trustedCertEntry

Owner: CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE
Issuer: CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE
Serial number: 40000000001154b5ac394
Valid from: Tue Sep 01 08:00:00 EDT 1998 until: Fri Jan 28 07:00:00 EST 2028
Certificate fingerprints:
         SHA1: B1:BC:96:8B:D4:F4:9D:62:2A:A8:9A:81:F2:15:01:52:A4:1D:82:9C
         SHA256: EB:D4:10:40:E4:BB:3E:C7:42:C9:E3:81:D3:1E:F2:A4:1A:48:B6:68:5C:96:E7:CE:F3:C1:DF:6C:D4:33:1C:99
Signature algorithm name: SHA1withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

If the above certificate is not present in the nx.keystore, or there is a problem with the certificate import attempt (usually done automatically by SDM during the above), you may also try importing the certificate file manually into the nx.keystore by doing the following in an Admin Command Prompt on the SDM Server:

1.  Run "nxcd bin" to access the SDM install directory's bin directory.

2.  Run "pdm_perl -list -v"
This will list all certificates in the keystore; write down the existing email certificate ALIAS NAME exactly as displayed

3.  Run "pdm_perl -delete [enter alias name here no brackets]"

4.  Run "pdm_perl -import "[path and location of newly updated .cer file]"

Example:  pdm_perl -import C:\certs\outlook_root.cer

5.  restart pdm_maileater_nxd and pdm_mail_nxd.

If manually adding the root CA certificate to the above nx.keystore is unsuccessful, follow this tech article which can be used to completely rebuild the nx.keystore from scratch: