[Skip navigation links]

Code Signing Certificates

Do I have to verify the identity of the person's name on the code signing certificate?

No, this is not a requirement for QuoVadis code-signing certificates.

What details are contained in a QuoVadis code-signing certificate?

A QV code signing certificate only has to have a Common Name and an Organisation name as a minimum. The Common Name must be the organisation's legal name only. It is optional to include OU and email address fields. Organisation validation is already done when an organisation is added to TrustLink; and this is adequate. The email address in the certificate (which is optional) may be generic or specify an individual, but the Registrant (whose details are not shown in the certificate) must be an individual at the organisation who is the Certifcate Holder for that Certificate.

What do I need to include in the Common Name field of a QuoVadis code-signing certificate?

It is is a mandatory requirement of the QV Root CA2 CP/CPS, version 1.16 (page 48) for the legal name of the organisation requesting the code-signing certificate to appear in the Common Name and the Organisation Name fields.

What types of code-signing certificates are available through QuoVadis?

QuoVadis provides policy templates for code-signing certificates that can be generated in two ways. Use the "Codesigning_cert" template to generate a key pair in the user's browser. Select the "Codesigning_CSR" to enable an end user to submit a CSR via TrustLink and then obtain a code signing certificate.

Does timestamping during the signing process extend the validity of a digital signature associated with an expired code-signing certificate?

Yes. The timestamp is a simple snapshot that basically says, this certificate was valid at a particular time. Hence, the digitally signed code (with timestamping) will continue to show as valid to a relying party, even though the certificate itself has expired. Timestamping delays 'expiration' until the timestamp expires which is usually 8+ years in to the future. Therefore, in effect, using timestamping during the signing process extends the period which a digital signature, when checked by a relying party, will be regarded as valid.

If you used the timestamping option during the code signing process, will the digital signature remain valid if the certificate is later revoked?

Yes. It will behave in the same way as if the certificate expires naturally. This is because, at the time the code was signed, the certificate was valid and hence the signature, when it was created was valid.

Timestamping therefore should be used selectively and with caution as it can pose a problem for relying parties where a code-signing certificate is subsequently revoked due to the compromise of a code-signing certificate private key. In this situation, if the compromised private key is used by a malicious party to sign code (with a timestamp), and then the compromise is discovered and the certificate is later revoked, the fraudulent digital signature on the malicious software will still show up to a relying party as valid.

Why does my revoked code-signing certificate appear to be valid when I open it in Microsoft Windows?

The reliable method to verify the validity of a certificate is to use the certutil.exe utility, which includes checks for CRL membership. To examine a certificate, run certutil -f -urlfetch -verify mycertificatefile.cer. For more about CRL checking, visit Basic CRL checking with certutil.

How do I use my code-signing certificate to sign Java archive (jar) files?

Please see the QuoVadis article on this topic.