3

I already tried googling but no luck. All search results always tell you how to check cert expiration manually, but that is not my question. Yes I can use OpenSSL for example, but what I am asking is how the SSL/TLS protocol does it, not how a user/human can do it.

The question:

We know that SSL/TLS handshake will fail if a certificate is expired. How does the SSL/TLS protocol determine if a certificate is expired or not? What is/are the mathematical functions being used to extract the validity date? Also to what "time reference" (or database?) does it compare the current validity date to determine if it is expired or not? Is it the time of the local machine or of some remote server or what?

10
  • 4
    The expiry date is part of the certificate. If you try to edit the expiry date in the certificate then the signature will be invalid and thus the entire certificate will also be invalid. You don't need to look anywhere else, just look at the certificate data for the expiration date.
    – slebetman
    Jan 15 at 15:15
  • @slebetman Yes, if we edit the expiry date then the hashes won't match. But the thing is, we DO NOT edit the expiry date. Nothing has changed on the certificate, what has changed is the current time. So, therefore, even if the current time is already past the expiry date, the hashes should still match because we did not edit anything. Right?
    – Noob_Guy
    Jan 22 at 2:29
  • If the current time is past the expiry date then the certificate is expired and is no longer valid
    – slebetman
    Jan 22 at 3:03
  • Obviously you can set your PC clock to 1999 in order to accept old certificates but this is you deliberately setting your clock to the past. A network service or web page cannot set your clock. A locally installed program maybe can (eg. a virus) but a locally installed program can do much worse than just changing your clock.
    – slebetman
    Jan 22 at 3:08
  • @slebetman Yes, but my point is, the method of hash comparison cannot tell if the certificate is expired or not. Because the hashes will still match. There must be other way/method to know if the certificate is expired.
    – Noob_Guy
    Jan 22 at 3:11

1 Answer 1

17

how the SSL/TLS protocol does it

The SSL/TLS protocol does not define how certificates are validated. You need to look instead RFC 5280, which is about certificates in general. SSL/TLS just makes use of established mechanism for certificate validation.

What is/are the mathematical functions being used to extract the validity date?

A certificate is simply a serialized data structure. The expiration date can easily be extracted when deserializing this structure. How the data structure looks like is defined in RFC 5280. The serialization method is ASN.1. There are many different implementations in different languages to do this.

Also to what "time reference" (or database?) does it compare the current validity date to determine if it is expired or not? Is it the time of the local machine or of some remote server or what?

I cannot see any explicit definition which time source should be use for comparison, but I think it is obvious that it should be one which is considered the correct one by the one doing the check. Usually this means the time on the local machine, which today often gets synchronized with the actual time. But it is a common source of validation failures if the local time is way off the actual time.

7
  • "SSL/TLS just makes use of established mechanism for certificate validation." - may I ask more about this? What are those established mechanisms? Also, are those mechanisms part of the SSL/TLS handshake?
    – Noob_Guy
    Jan 14 at 6:43
  • 1
    @Noob_Guy: "What are those established mechanisms?" - RFC 5280. "Also, are those mechanisms part of the SSL/TLS handshake?" - the handshake is about transporting the certificate and expecting the application to verify it. The verification itself is not part of the TLS specification. It is usually done within the time of the handshake, i.e. usually once the certificate is received. It must be done at least before exchanging application data, so it might even be done after the handshake itself has finished. Jan 14 at 7:16
  • Ok thanks. Just one more clarification please.. If the cert verification is not part of SSL/TLS specification, does it mean it is optional? What happens if we dont verify the certificate? And if it is not optional, then what specification mandates it?
    – Noob_Guy
    Jan 14 at 7:35
  • 3
    @Noob_Guy: from RFC 8446 (TLS 1.3): "The server side of the channel is always authenticated". It does not mandate certificates for this, but this is the most common way. Without server authentication the client does not know if it communicates with the intended server or some attacker impersonating the server (for example during a MITM attack) Jan 14 at 7:40
  • 2
    @Noob_Guy it is optional. Most systems have an option to skip it. Web browsers make this difficult for the user to do, because it removes most of the safety provided by TLS.
    – OrangeDog
    Jan 14 at 16:26

You must log in to answer this question.

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