8

Looking at a certificate for a web-site (in Windows/Google Chrome) I see it lists the following fields

  • Version
  • Serial number
  • Signature algorithm
  • Issuer
  • Valid from
  • Valid to
  • Subject
  • Public Key
  • Basic Constraints
  • Certificate Policies
  • CRL Distribution Points
  • Enhanced Key Usage
  • Key Usage
  • Subject Alternative name
  • Authority Information Access
  • Thumbprint algorithm
  • Thumbprint

Under some circumstances, the browser conveys what the problem may be.

E.g.

  • Certificate not yet valid/expired: In this scenario either 'Valid From', or 'Valid To' is bad

  • Certificate for a different web-site: In this scenario 'Subject' is bad

I remember being told that on a suspicious certificate some fields should be verified manually/explicitly. I can't remember which fields amongst the above are relevant, nor what to look for in these fields.

For instance, what would happen if the field "Basic Constraints" in the certificate is bad? Or if the field "Certificate Policies" is bad?

Which fields in a suspicious certificate should I look at?

EDITED: Useful responses all around. Thank you!

What is the significance of the fields 'Basic Constraints', and 'Certificate policies'? I took a look at the RFC5280 but am too dense to figure out the significance to the description

Community
  • 1
Everyone
  • 387
  • 3
  • 10
  • I for the most part ignore them, unless they are for banking or shopping and that's when you've got to be aware. –  Dec 16 '11 at 15:18
  • 1
    Amazing nobody asked what exactly do you mean by "suspicious"? In general if you take time to look at a certificate you want to check the issuer and subject identities but beyond that the answer depends on the context and what specifically makes the cert suspect. – T.Rob Dec 30 '11 at 20:21
  • @T.Rob: Good call. Suspicious would be either when the browser has already identified some problem with the certificate, or when I wish to verify the certificate presented by a site personally. – Everyone Dec 31 '11 at 05:17

4 Answers4

5

Look at the Issuer field also! As discussed at How feasible is it for a CA to be hacked?, you really can't trust all the Certificate Authorities out there, and actually the whole CA model is flawed. So one field to look at is the Issuer field, and you might want a browser feature that notices if you're looking at a certificate issued by an untrustworthy CA. This covers both CAs owned or overly influenced by countries that you don't want to trust with your data, or CAs that have flawed security or issuance procedures and have mistakenly certified fraudulent certificates.

Another case you should be alert for is the case in which your proxy server issues certificates via a CA which has been baked into your browser - something that some organizations do because they don't trust their employees. See e.g. some of the corporate proxy software like Blue Coat, which may also be used in Syria.

Community
  • 1
nealmcb
  • 20,693
  • 6
  • 71
  • 117
3

Well, that somehow depends on the degree of professionalism of the website you are visiting and the sensitivity of the information you share with the website.

  • If it is your bank's website or the website asks for your credit card information, I would not tolerate any errors.

  • A website like MDN does not handle any sensitive information (except for your MDN password), but it is managed by professionals. Any error here is suspicious.

As for the particular errors you mention:

  • Certificate not yet valid, discarding the possibility of a mayor screw up by the website's admin, usually means that your computer's system clock is not set properly. Start with checking that.

  • Certificate expired usually means exactly that. This can happen on semi-professional websites, but this will not happen on your bank's website.

  • Certificate is for a different web-site is also common on semi-professional websites.

    • If the site you are visiting is foo.example.com and the certificate is for bar.example.com, check if both sites belong to the same service (e.g., billing and support). If they are, the admin missed a class or two when learning how to setup a website, but there is no real issue.

    • If foo.example.com and bar.example.com belong to different services (e.g., blogs by different people), do not go any further.

    • If you are visiting example.com, but the certificate is for scam.com, do not go any further.

  • Certificate is not trusted means that the certificate was not signed by a trusted certificate authority.

    • Anyone can create a certificate for yourbank.com and sign it himself, but the certificate from a professional website will always be signed by a trusted certificate authority.

    • Semi-professional and private websites often use self-signed certificates, since they are easy to create and free. The problem is that, while they do provide secrecy (encryption), they do not provide any confidentiality (anyone could forge the certificate). If the site asks for information you not not enter on an unencrypted website, do not proceed.

Dennis
  • 230
  • 2
  • 6
  • The responses you elaborate are what the Browser provides apropos any of the fields as Valid From/Valid To/Subject. I'm looking to learn the significance fields relevant in a suspicious certificate ... – Everyone Dec 16 '11 at 19:35
  • The fields that correspond to the responses I have listed are **Valid from**, **Valid to**, **Subject** and **Issuer** (in that order). –  Dec 16 '11 at 19:45
3

It is useless to look at the fields: whether a certificate is valid or not is the product of a complicated algorithm (see section 6 of RFC 5280 -- but do not do that if you want to keep your sanity more or less intact) and the browser is better than you at running that algorithm (many browsers are actually quite bad at it, but human beings are just worse). Careful manual analysis may end up with pointing out the plausible point on which the server owner or his CA got it wrong; but you cannot logically exclude the possibility of an attack. If the browser says "that's not good", then that's not good. If there was an easy way to "salvage" a bad certificate, then the browser would also implement it and would not report an error.

The only fields which are really worth looking at are the validity dates: there are two common situations which become manifest by a "certificate expired" or "certificate not yet valid" message, and at least one of them can be resolved on your side:

  1. The certificate expired a few hours ago. The server owner forgot to renew it in time. Since revocation checks are by nature asynchronous, you may decide to tolerate a slightly out of date certificate (by "slightly" I mean "by one or two days at most"). That's your decision.

  2. The certificate is actually currently valid; that's your computer which has a wrong clock. If the start and end dates of validity of the certificate seem to enclose the current date, it is time to check whether the date and time are correctly configured on your machine. For instance, I have an old laptop which has a tendency to switch back to 1969 when left alone for more than a few days.

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
-1

What other checks other than valid fromand valid to can you make? It's the same as if someone gives you (I'm supposing you're located in India) gives you a bank note from Argentina. How do you check that it is valid?

ott--
  • 128
  • 1
  • 1
  • 9