Signature verification: Which steps are necessary to validate / verify a certificate?

Overview

X.509 certificates are digital data, which means that anyone can create an X.509 certificate with any content. Due to this fact, several mechanisms have been put in place to verify that a certificate is valid and trustworthy.

Trust

A central concept when checking X.509 certificates is trust. Trust in a certificate is a necessary condition for the validity of a certificate. Most of the time, software that uses X.509 certificates is delivered with one or more root certificates, which the software (e.g. Microsoft certificate management) evaluates as “trusted” a priori. In addition, the EU member states maintain their national trust lists, which are summarized in the European trust list (EU Trust List EUTL). It contains qualified trust services in accordance with the eIDAS-VO.

Certificate Verification

The following steps are carried out (not necessarily in this order) to check the validity of a certificate:

• Verification of the signature
• Verification of the validity period
• Checking the revocation status
• Verification of trust (certificate path)

If one of these steps fails, the certificate is invalid and, depending on the software, a more or less exact error message or warning is issued.

Verification of the signature

Each X.509 certificate is signed with the private key of the issuer of the certificate. The signature can be checked using the associated public key. If the signature verification fails, the document was a) never signed or b) the document has been modified since the signature.

Gain an overview of all our Signature and Trust Services

Verification of the validity period

In each X.509 certificate, a period of validity is specified by means of a start date and an end date. If the current system time is before the start date or after the end date, this check is negative. Depending on the type of certificate, different upper limits are set for the period of validity. For SSL certificates, currently around 1 year.
Expired certificates can no longer produce valid signatures – however, signatures set before expiry remain valid later. Software that issues an error here does not work in accordance with the standard.

Checking the revocation status

Each X.509 certificate can be revoked by the issuer. Information is stored in the certificate on how the revocation status of the certificate can be checked. The check can trigger a connection from the checking software to a server of the issuer, which is used to query the revocation information. GLOBALTRUST offers the methods CRL and OCSP to check the revocation status. The revocation status check fails if a) the connection to the revocation information server fails or b) the checking software receives the information that the certificate has been revoked.

Especially with OCSP it is necessary to actually be online. It is sufficient if port 80 is enabled for this check. If the direct connection cannot be secured, online verification should be disabled. Some software then brings up a message in the form that a “Check of the current validity status of a certificate could not be carried out”. However, this does not affect the actual validity of a signed document.

If there are justified doubts about the validity of a document, there is always the option of inquiring directly with GLOBALTRUST. Then the validity is checked manually. If asked, GLOBALTRUST needs the serial number of the certificate, the name of the certificate and the date the document was signed.

Verification of trust (certificate path)

During this check, the checking software searches for the issuer certificate of the certificate to be checked and carries out a complete certificate check of this certificate. Of course, this again triggers a check of the issuer certificate of this certificate, and so on, until a certificate is checked where the issuer and subject are the same (self-signed certificate – root certificate). This check ends successfully if, in the course of checking this certificate path, a certificate is found that the software trusts (see the “Trust” section). It fails if a) an issuer certificate cannot be found or b) the verification has arrived at the end of the certificate chain (self-signed certificate) and this certificate is not trusted.

Useful tools for certificate and signature verification

• Signature and seal verification RTR: https://www.rtr.at/TKP/was_wir_tun/vertrauensdienste/Signatur/signaturpruefung/Pruefung.en.html
• Signature and seal verification EU Commission: https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/validation
• Certificate verification EU Commission: https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/certificate-validation
• ETSI Signature Conformance Checker (access required): https://signatures-conformance-checker.etsi.org/pub/index.php