0

I don't really understand why the approach towards checking the validity of certificates is "valid until proven otherwise" (aka revocation lists).

In my opinion this is kind of weird. A CA has to manually keep track of all the certificates it issued and explicitly revoke the ones that shouldn't be authenticated any more.

Wouldn't it make more sense to force CAs to keep databases with the certificates they issued or even better: have each certificate signed with a seperate key that is stored in the CAs database and if you want to revoke the certificate you just have to delete its entry?

Because if you look at use cases like client certificates on Apache for instance you always have to keep track of the certificates you issued (e.g. for each employee in a company). Once an employee leaves the company you have to revoke his/her certificate. But without ssl/tls by default forcing you to to have an "active certificates list", doesn't this create margin for errors (aka forgetting to revoke a client certificate)? I mean there are other means to keep track of that (databases, LDAP etc.) but shouldn't the "not valid until explicitly validated"-approach not at least be an option? Or is there a solution for that (except from third party software)?

And furthermore: Why is the CRL-URI in a DigiCert certificate http and not https, doesn't this mean I can just spoof this address and return a "everything is fine and dandy"-CRL to the client?

I mean the DigiCert CRL has a signature under it which proves to the client that this is a valid CRL issued by the CA but is this mandatory? E.g. do browsers demand a signature under each crl they receive and what do they do if they don't get any crl at all?

Broco
  • 128
  • 7
  • 2
    *"Why is the CRL-URI in a DigiCert certificate http and not https"* is covered in my question [Is publishing CRLs over HTTP a potential vulnerability?](https://security.stackexchange.com/q/72570/2138) from back in 2014. – user Sep 25 '18 at 14:15
  • Ah thank you very much, good to know it's mandatory. The other question still persists though. Should I remove the second question then as to not confuse readers? – Broco Sep 25 '18 at 14:26

4 Answers4

2

A revoked certificate is an exception, not the rule. So you accept every certificate as valid, and create a database with the invalid ones, a very small minority.

have each certificate signed with a separate key that is stored in the CAs database

Each certificate is already signed with the CA key. Having 2 keys does not add anything.

and if you want to revoke the certificate you just have to delete its entry?

This increases complexity. Each time you download a certificate you would need to connect to the CA to ask if the certificate is still valid.

doesn't this create margin for errors (aka forgetting to revoke a client certificate)?

This process must be automated. When you terminate a user's account, the process must revoke his accounts, his credentials, and his certificates.

but shouldn't the "not valid until explicitly validated"-approach not at least be an option?

And you would need a solution to validate the validation, and a solution to validate the validated validation, and so on. One revoke action is better than to validate and validate again.

Why is the CRL-URI in a DigiCert certificate http and not https, doesn't this mean I can just spoof this address and return a "everything is fine and dandy"-CRL to the client?

From Digicert itself:

It is digitally signed by an IA and issued periodically or as needed.

So, you cannot. If you spoof the address and forge the CRL, you cannot sign the CRL and nobody will believe you are Digicert.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
1

First bear in mind that X.509 was designed at times not every system was online all the time.

Having only serial numbers of revoked certificates on a certificate revocation list (CRL) was mainly done for keeping the size small. Some CAs also remove revoked certs which expired in the mean-time from the CRL for exactly this reason. More sophisticated approaches for addressing CRL size are partitioned CRLs and delta-CRLs.

Today many PKI deployments favor online revocation checks like OSCP. At first this also was just designed to indicate revocation (sometimes read from CRL) but some OCSP responders also query the CA's database. There was even a remote validation mechanism designed called SCVP which is not widely implemented though. OSCP et al strictly require online access.

Like X.509 certs the X.509 CRLs are also signed either by the CA itself or by another delegated revocation authority (indirect CRLs). So it's no problem to distribute them via clear-text and unauthenticated HTTP as long as the relying participant properly validates the signature. (Using HTTPS might cause hen-and-egg problems while checking the TLS server cert against an CRL).

Community
  • 1
Michael Ströder
  • 307
  • 1
  • 6
  • Ok, now that makes sense. So basically the revocation approach is just a relict of the past and the CRLs are kinda obsolete for most clients nowadays and servers can come to the "ok"/"not ok"-conclusion in many different ways but still keep CRLs for backward compatibility, do I get that right? – Broco Sep 25 '18 at 14:46
  • 1
    Mainly yes. Still CRLs can serve as authorative source for revocation and still I believe, once you've downloaded a CRL in the cache it is the most performant way of revocation check. – Michael Ströder Sep 25 '18 at 14:48
1

Wouldn't it make more sense to force CAs to keep databases with the certificates they issued

Certificate Transparency is sort of like that, but better.

have each certificate signed with a seperate key that is stored in the CAs database and if you want to revoke the certificate you just have to delete its entry?

How is that any better than a CRL? Having a separate key for each certificate seems pointless and needlessly complicated.

Because if you look at use cases like client certificates on Apache for instance you always have to keep track of the certificates you issued (e.g. for each employee in a company). Once an employee leaves the company you have to revoke his/her certificate.

This is a very different use case. With a client certificate you're already sending it to that Apache server, so it can just check its local revocation list.

You could force a check against the CA to see if a certificate is still valid every time you visit a site (that's what OCSP is), but that comes with plenty of its own issues (though many of these issues are solved by stapling).

Why is the CRL-URI in a DigiCert certificate http and not https, doesn't this mean I can just spoof this address and return a "everything is fine and dandy"-CRL to the client?

It's signed anyway, so authenticity is already provided, and confidentiality isn't really necessary.

We have to tools to do revocation properly: OCSP stapling combined with Must-Staple (which tells browsers not to soft-fail if OCSP is missing). The real problem is that no one implements them correctly.

AndrolGenhald
  • 15,436
  • 5
  • 45
  • 50
  • Ye I agree, the check for the serial number makes more sense complication wise as it serves the same purpose and another key doesn't add security. Thanks for the links, that was an interesting read especially that the stapling implementation is so bad in Apache. – Broco Sep 25 '18 at 15:18
0

CRL's are designed for getting downloaded by whoever needs to check for revocation. Getting the list of all valid certificates from the CA instead of getting only the list of the revoked ones would make a huge difference and what one would need to download.

Also, CRL's are designed for caching and have a kind of expiration where a new CRL should be downloaded. While it is acceptable to fail to detected a revoked certificate for a short time (until the CRL update) it would be unacceptable to not accept a valid certificate until the next update of the list of valid certificates.

.. you always have to keep track of the certificates you issued

The CRL does not contain the whole certificate, only its serial number. So a CA only needs to know the serial number for the specific certificate to be revoked and does not need to keep track of the full certificate.

Why is the CRL-URI in a DigiCert certificate http and not https, doesn't this mean I can just spoof this address and return a "everything is fine and dandy"-CRL to the client?

CRL's are signed, thus faking a CRL is not possible unless the private key of the CRL issuer (i.e. the CA) is stolen.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • I didn't mean that each client should download the entire list, just send the public cert (or serial number) to the ca and ask if it's valid and get a "valid entry found" or "no valid entry found" in response. I understand that the entire list would be too big. – Broco Sep 25 '18 at 14:31
  • @Broco That's how OCSP works. – Ajedi32 Sep 25 '18 at 14:32
  • @Broco: Then don't ask about CRL. For checking the status of a single certificate directly with the CA OCSP is used. – Steffen Ullrich Sep 25 '18 at 14:32
  • @SteffenUllrich that wasn't clear to me. I thought OCSP does the same, basically ask the server and the server looks up in his own crl and replies to the client. My question was more about the "trust until revoked"-approach and if it wouldn't be more feasable to do the opposite "don't trust until validated". Basically server-side only. – Broco Sep 25 '18 at 14:34
  • See my answer: Yes, the OCSP status was just meant to say "revoked" or say nothing. – Michael Ströder Sep 25 '18 at 14:40
  • That wasn't the question, the question was about how the server comes to this conclusion, looking at a "list of revoked certs" vs "list of allowed certs". Sorry if that wasn't clear. – Broco Sep 25 '18 at 14:42
  • 1
    @Broco: how does it matter for the validity check if there is a whitelist of valid certificates or a blacklist of revoked certificates as long as these lists are complete and up-to-date? – Steffen Ullrich Sep 25 '18 at 14:42
  • See the question: When you have a mandatory whitelist-approach it's easier to keep track of the issued certificates. It eliminates the margin for errors (e.g. forgetting to revoke a certificate). – Broco Sep 25 '18 at 14:48
  • @Broco: How is deleting a certificate from a whitelist less error prone than adding a certificate to a blacklist? The same as one can forget to add it to the blacklist for revocation one can forget to delete it from the whitelist. – Steffen Ullrich Sep 25 '18 at 14:53
  • If you have a whitelist you actually can SEE the clients that are on your whitelist (e.g. see the cert of an employee that's no longer there) as opposed to just not see him. Given the company example you can compare a list of current employees with your whitelist. The same reason why when administrating a server you don't give folder permissions by allowing everyone access to a folder EXCEPT Bob, Alice, Charles and Clinton **but instead** explicitly allow Susanne and nobody else. – Broco Sep 25 '18 at 15:10