In the scenario where "Application A" wants to communicate with "Application B" over an API (HTTPS), I want to ensure mutual authentication is implemented. Meaning that "A" should authenticate "B" before it authenticates itself. A CA signed certificate will be held on "B" to enable HTTPS.

When "A" initiates the TLS(1.2) connection with "B", does "A" authenticate "B" by default using TLS? Meaning does "A" verify that the endpoint certificate (CN) on "B" matches the domain name? If the domain name checking is not done I would assume this would not be sufficient for server authentication as the application will initiate the connection regardless of what certificate is presented on "B"?

I understand web browsers implement domain name checking, but was not sure if this was built into the TLS protocol and will therefore be implemented by default in application to application connections.

Update/Answer: This URL provides specific answers to my question: https://stackoverflow.com/questions/17279683/how-can-you-test-that-an-ssl-client-library-is-properly-verifying-the-certificat

  • Web Protocols actually don't do that. In fact, HTTPS is actually "HTTP over TLS", meaning that a lot of what is going on at the HTTP layer is blissfully unaware whether it is sent in plaintext or through an encrypted tunnel.
    – user163495
    May 6, 2020 at 17:08
  • @MechMK1 agreed, hence why my question was does "TLS" provide server authentication rather than HTTP/HTTPS. May 6, 2020 at 17:12

1 Answer 1


RFC 8446 (TLS 1.3) says:

Implementations are responsible for verifying the integrity of certificates ... Absent a specific indication from an application profile, certificates should always be verified to ensure proper signing by a trusted certificate authority (CA)

The spec seems to say that verification needs to be supported, but doesn't exactly require it (SHOULD vs MUST), and leaves it up to the implementation and application.

There isn't a single "TLS" either. There are many different implementations, although OpenSSL is probably most common. Reading their wiki, it seems that the defaults are fairly sane and should handle verification.

However, the application gets to decide if verification is actually used. So it's possible that a poorly developed application may have verification turned off.

  • Updated my question to state TLS 1.2 will be used, however I suspect it would be similar in TLS 1.2? I guess the only way to confirm in my example would be to put an invalid certificate on Application B and see if Application A still proceeds with the connection as normal. May 6, 2020 at 18:32
  • @user1876202 You seem to misinterpret the RFC. "Implementations are responsible" means it has nothing to do with TLS 1.0, 1.1, 1.2, etc. The library or binding you use needs to verify this, or has to give you the option to verify it.
    – user163495
    May 6, 2020 at 19:11
  • Thanks both this does make sense, I found this post which addresses my exact question in more detail: stackoverflow.com/questions/17279683/… May 6, 2020 at 19:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .