Confused :: expiry warning for non-expiring certificate

In the context of:

You're indicating root access to the system (otherwise, you couldn't read the private key). If you have root access to the (web) server, you can pass another domain validation challenge, either under the same ACME account, a new ACME account, or a completely different (possibly non-ACME) CA. Automatic revocation would make things more complicated for everyone from ACME servers to client developers to users who lose their account keys, while the added security benefits are easy to bypass.

Plus, we haven't even talked about the fact that revocation doesn't work anyway. :blush:

I thought we just established that there is a public (and cryptographically assured!) record of all certificates issued for your domain? :smile:

I see a X509v3 Subject Alternative Name section for both certificates on that list. Did you click on the "Not Before" link to get to the actual certificate?

Yes, CN for a certificate in the web PKI today must match a SAN. This implies there must be at least one SAN.

New non-compliant certificates are rare but there are definitely enough in the wild that Firefox e.g. can't just disable the back compatibility. Still this is definitely something CAs get jumped on for when they apply to add or replace roots, or even just generally if they poke their heads up. If I'm looking at applications from a CA that can't do this right in 2016, my starting stance is "You're incompetent, why would anybody trust you to tie your own shoelaces, much less issue certificates?".

I see a X509v3 Subject Alternative Name section for both certificates on that list. Did you click on the "Not Before" link to get to the actual certificate?

Yeah, sorry, I was getting way ahead of myself, clicking on "Not Before" for the Issuer's certificate :blush: , I see it now.

I thought we just established that there is a public (and cryptographically assured!) record of all certificates issued for your domain? :smile:

So;

Oh, and just in case you thought it couldn't get any worse: Certificate Transparency is currently a voluntary thing, and many CAs don't submit their certificates to log servers (Let's Encrypt does), so if the attacker picks a CA that doesn't support Certificate Transparency, you probably won't notice anything. On the bright side, there's a good chance browser vendors will start enforcing Certificate Transparency somewhere within the next couple of years. :grimacing:

Means there is always a public record so long as I use LetsEncrypt? :slight_smile:

Plus, we haven't even talked about the fact that revocation doesn't work anyway. :blush:

You're not 'selling' your service here! ... :wink:

There's two ways to answer that question:

  • Yes, any certificate issued by Let's Encrypt (as requested by you or someone who has compromised your server) will have a public record.
  • However, if your server is compromised, the attacker is not limited to Let's Encrypt, and could just request a certificate from a CA that does not log their certificates - so no public record. :worried:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.