Skip to page contentSkip to chat
ServiceNow support
    • Community
      Ask questions, give advice, and connect with fellow ServiceNow professionals.
      Developer
      Build, test, and deploy applications
      Documentation
      Find detailed information about ServiceNow products, apps, features, and releases.
      Impact
      Accelerate ROI and amplify your expertise.
      Learning
      Build skills with instructor-led and online training.
      Partner
      Grow your business with promotions, news, and marketing tools
      ServiceNow
      Learn about ServiceNow products & solutions.
      Store
      Download certified apps and integrations that complement ServiceNow.
      Support
      Manage your instances, access self-help, and get technical support.
Mutual authentication to end point fails with javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate - Support and Troubleshooting
  • >
  • Knowledge Base
  • >
  • Support and Troubleshooting (Knowledge Base)
  • >
  • Mutual authentication to end point fails with javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
KB0683345

Mutual authentication to end point fails with javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate


15198 Views Last updated : Feb 7, 2025 public Copy Permalink English (Original)
  • English (Original)
  • Japanese
KB Summary by Now Assist

Issue

When establishing SSL connections to 3rd party end-points, the default settings on the instance's HTTP client protocol could interfere with their defined handshake.

  • When a client requests the server certificate for authentication, a certificate signing request (CSR) is generated.
  • To respond to a CSR, the server generates two unique cryptographic keys: A public key, which is used to encrypt messages to the server, and a private key, which is used to decrypt messages. Both keys are kept in the Key Store.
  • Keys are used to decrypt the client's secure messages so they can be read by the server. Any outgoing connection that is going to be HTTPS verifies the certification by checking the Key Store, offering its public certification, and they use the trust store certificates to verify mutual trust back.
  • To complete the secure link between the client and the server, the server matches the certificate to the corresponding private key. Because only the server has access to the private key, the server can decrypt the data from the client.

The problem appears if these settings do not match with the end-point setup, and you could receive an error of bad_certificate

Mutual authentication

Symptoms

You will have this problem if:

  • Connections to the system using non-mutual authenticated services work fine.
  • You have multiple keystores installed.
  • Testing on SOAP UI or other tools against the mutually authenticated end-point, you've also received a bad_certificate error.
  • Setting the properties to empty, or to match the end-point setup for SSL handshake resolves the problem.

Cause

There are several possible reasons. Here is an example of a command that registers MYHTTPS with the com.glide.certificates.DBKeyStoreSocketFactory socket factory on port 443. The database key store factory is used during the SSL exchange process to offer a client certificate for mutual authentication.

glide.httpclient.protocol.myhttps.class = "com.glide.certificates.DBKeyStoreSocketFactory"
glide.httpclient.protocol.myhttps.port = "4433"

In this case, if the end-point SSL socket factory is different from 4433, it could fail with an error.

Resolution

Se the value of the properties glide.httpclient.protocol.myhttps.class and glide.httpclient.protocol.myhttps.port to empty. If this does not work, match your mutual authentication profile value accordingly to the setup for your end-point.

Once you have uploaded the CA-signed certificate to the instance of your end-point, and you have created separate certificate records for them, you should simply update the key-store reference field on the existing myhttps protocol profile. If you create another protocol profile for the testing or the production environment, you might run into connection errors when trying to connect to the target system. Therefore, in order to prevent some unexpected behavior, keep only one protocol profile named myhttps, and simply update the references to the CA-signed key-store.  Also, make sure the key-store file name contains only small letters, as you might end up having authentication issues.

 Note: Overriding the default HTTPS protocol socket factory affects every outbound HTTPS connection. This is usually undesirable.

Related Links

  • SSL on SOAP Outbound message (Community)
  • Mutual authentication (docs)

The world works with ServiceNow.

Sign in for more! There's more content available only to authenticated users Sign in for more!
Did this KB article help you?
Did this KB article help you?

How would you rate your Now Support digital experience?

*

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

What can we improve? Please select all that apply.

What are we doing well? Please select all that apply.

Tell us more

*

Do you expect a response from this feedback?

  • Terms and conditions
  • Privacy statement
  • GDPR
  • Cookie policy
  • © 2025 ServiceNow. All rights reserved.