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. – MechMK1 May 6 at 17:08
  • @MechMK1 agreed, hence why my question was does "TLS" provide server authentication rather than HTTP/HTTPS. – user1876202 May 6 at 17:12

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.

| improve this answer | |
  • 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. – user1876202 May 6 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. – MechMK1 May 6 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/… – user1876202 May 6 at 19:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.