60

I am cleaning up the certificate stores on my Windows machines, and considering which certificates I should keep, and which ones I should delete.

Why does a fresh install of Windows Server 2012 R2 come with certificates such as these:

Expired Certs

Considering that these certificates expired back when I was in high school, what could they possibly be good for? Why would they still be included with the operating system 15 years later?

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
Ryan Ries
  • 949
  • 1
  • 10
  • 14

2 Answers2

65

In essence, these certificates are necessary and required for backward compatibility with XP and Server 2003. If anything was signed with these certificates, even if they're expired now, your server needs the cert trusted in order to trust the thing that the cert signed.

Source: http://support.microsoft.com/kb/293781

Some certificates that are listed in the previous tables have expired. However, these certificates are necessary for backward compatibility. Even if there is an expired trusted root certificate, anything that was signed by using that certificate before the expiration date requires that the trusted root certificate be validated. As long as expired certificates are not revoked, they can be used to validate anything that was signed before their expiration.

MDMoore313
  • 978
  • 9
  • 14
  • 5
    I'm going to do something crazy and delete the certificates from the 20th century. I don't believe I'm using any arcane stone-age kernel drivers, so I bet I'll be OK... – Ryan Ries Dec 17 '14 at 04:56
  • 5
    @RyanRies seems reasonable; worst case if you do find a legacy app that needs them, you can always add the cert back. – Dan Is Fiddling By Firelight Dec 17 '14 at 05:15
  • @RyanRies Maybe surprising but not the kernel driver signaturing is the only thing where your windows need to validate things... I suggest to try at least 1 non-m$ operating system. – peterh Dec 17 '14 at 14:33
  • 1
    Wait a sec, but since they expired they aren't supposed to be trusted by the windows anyway, no? – Cthulhu Dec 17 '14 at 14:58
  • 6
    @Cthulhu if they signed something before they were expired then that makes that signature valid, according to Microsoft – MDMoore313 Dec 17 '14 at 15:11
  • 14
    Not only Microsoft but all standard conforming certificate validation! (Only for counter-signed timestamps, obviously). It only makes sense this way. A certificate confirms the identity of someone. If he signed something with a valid certificate a year ago, it is still signed by the same person, even if the certificate is expired! – Josef Dec 17 '14 at 17:08
  • Thanks @Josef, I figured but I didn't want to conjecture without actual proof, I'm not what you call a PKI expert, yet – MDMoore313 Dec 17 '14 at 17:11
  • 3
    Don't forget to turn off Automatic Root Certificates Update via Group Policy or Local Computer Policy, or else Windows will automatically re-download these certificates and put them back in your Trusted CAs store after you've deleted them. – Ryan Ries Dec 17 '14 at 21:24
  • 1
    @Josef: But if the signing certificate is expired, then [we don't know whether it has been compromised](http://security.stackexchange.com/a/31482/6816), so we can't confirm the premise that "he signed something with a valid certificate a year ago". Perhaps it's an attacker who signed it, with the compromised certificate, much more recently (and with a faked timestamp). – ruakh Dec 18 '14 at 01:57
  • As I mentioned this only works with signed timestamps! For windows executable files, this can be done using the legacy PKCS#7 countersignature timestamping[1] or RFC 3161 based timestamping[2] ( [1] http://msdn.microsoft.com/en-us/library/bb931395%28v=vs.85%29.aspx [2] https://www.ietf.org/rfc/rfc3161.txt ) – Josef Dec 18 '14 at 02:42
  • also @ruakh if the certificate has been *revoked*, it doesn't matter if it's expired or not, revokation kicks in if there is CRL checking enabled. So, unless the server knows it's compromised, it has to assume it isn't. It can still check the CRL for expired certs. – MDMoore313 Dec 18 '14 at 15:53
  • @BigHomie: So you're saying that Thomas Pornin is mistaken (in the answer I linked to)? – ruakh Dec 18 '14 at 18:25
  • @ruakh yes, I actually upvoted that answer back in the day when it was popular just *because* it was popular, without fact checking first, because it sounds like it *should* be right. You can see my recent comment [here](http://security.stackexchange.com/questions/31463/why-do-we-not-trust-an-ssl-certificate-that-expired-recently/31482#comment125289_31482), it's only half true. By default CAs do not include that information, but at least RedHat and Microsoft CAs have options to include that information. You honestly brought up a good point though. – MDMoore313 Dec 18 '14 at 18:45
1

Some of these older Root Certificates have been used to generate 'Time Stamping' or 'Code Signing' certificates. This means a piece of executable code has been digitally signed way back. These Root Certs may still be needed, so your PC can validate that the code signing was valid AT THE TIME OF SIGNING. Which can be of course also way back.

Deleting these old certs may cause your PC to claim that an old piece of software can no longer be validated for authenticity.

Erwin
  • 11
  • 1