3

I have this executable, written in vb.Net and compiled to a Windows executable for .Net Framework 2.0. Because we use software whitelisting to prevent unknown Software on our Windows clients, this executable is strongnamed and signed using Visual Studio 2008 Professional workflow:

<SignFile
  CertificateThumbprint="1f 6c ... 33 b2"
  SigningTarget="$(TargetPath)"
  TimestampUrl="http://timestamp.verisign.com/scripts/timstamp.dll"
  ContinueOnError="false"
/>

For this, we run a corporate RootCA, an intermediate CA for each corporate Branch and below each of these an issuing CA. "My" Issuing CA provided a Codesigning Certificate to me, wich expired a couple of months ago.

Because I used a Trusted Timestamp (Authenticode) in my workflow, the signature was / is still valid when examining it via its file properties, users are still able to execute it without triggering the Windows AppBlocker. All is good.

Now, I am told my certificate is revoked wich I can verify by looking at the crl. According to CA management, it should have been invalid for a month now but the signature is still valid.

Serial Number: 16C40CA0000000002A60
Revocation Date: Aug 10 06:18:00 2015 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Cessation Of Operation

What I believe is that the Reason provided in the crl causes this. According to RFC 3161, §4 Bullet 1:

When a TSA shall not be used anymore, but the TSA private key has not been compromised, the authority's certificate SHALL be revoked. When the reasonCode extension relative to the revoked certificate from the TSA is present in the CRL entry extensions, it SHALL be set either to unspecified (0), affiliationChanged (3), superseded (4) or cessationOfOperation (5). In that case, at any future time, the tokens signed with the corresponding key will be considered as invalid, but tokens generated before the revocation time will remain valid. When the reasonCode extension relative to the revoked certificate from the TSA is not present in the CRL entry extensions, then all the tokens that have been signed with the corresponding key SHALL be considered as invalid. For that reason, it is recommended to use the reasonCode extension.

So my Question / Problem consists of:

  1. Does RFC 3161 also apply to codesigning certs or TSAs only?
  2. If yes, are Signatures still valid if made before revokation with reason 5 CessationOfOperation?
  3. If yes, can / should certificates be revoked again using a different reason if found compromised after it is expired? There still may be hundreds of valid signatures!
Community
  • 1
  • 1
Stephan B
  • 3,671
  • 20
  • 33
  • To de-mystify this a bit, our clients may simply have a problem fetching the crl. This is currently checked, this may not be a certificate-problem at all. – Stephan B Sep 03 '15 at 14:19

2 Answers2

3
  1. No, specified RFC describes timestamp protocol and timestamp authorities. It has nothing to do with codesign certificates
  2. Yes, signatures made before the time of revocation are considered valid
  3. A certificate can not be revoked multiple times. If it is revoked then it's revoked.

Now, I am told my certificate is revoked wich I can verify by looking at the crl

I assume that your certificate is a codesign certificate. The reason why your application is still working is that a timestamp was used when you signed your application. Timestamp guarantees that the your signature was made at specified time. And at this time your certificate was valid.

pepo
  • 8,644
  • 2
  • 27
  • 42
0

Last time I looked into it, I recall it as follows: When an executable is started, no network connections can be attempted to verify whether the certificates used for the signing are still valid. Furthermore, for a signature to be valid, the certificate must have been valid at the time of signing - the cited RFC concurs with that. There is no way to revoke such signatures retroactively other than by removing the root CA from the list of valid root CA certificates. If you merely remove or revoke something up the chain, the chain bundled in the executable will still chain down to the root and thus validate.

Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313