Implement Certificate Revocation List (CRL) and OCSP validation for X.509 certificate-based commit signing

Based on Slack conversation with @pzapf

Summary

Currently, GitLab extracts CRL URLs from X.509 certificates and stores them in the database, but does not perform actual validation against Certificate Revocation Lists (CRL) or Online Certificate Status Protocol (OCSP) when validating certificate-based commit signatures.

Problem

A self-managed customer using X.509 certificate-based commit signing requires proper certificate revocation validation. Currently:

• GitLab extracts CRL URLs from certificates and stores them in the database
• No validation attempts are made to read the content of these URLs
• Certificates without distribution points are rejected, but revocation status is not actually checked
• This creates a security gap where revoked certificates may still be accepted for commit signing

CRL implementation

• Purpose: To provide a way to check if a digital certificate is still trusted, even if it has not yet expired.
• Content: A list of serial numbers of revoked certificates, along with the date of revocation and the reason.
• Generation: Issued by the CA that originally issued the certificate. Format: Based on the X.509 standard.
• Distribution: Published at a public location, often as a downloadable file specified in an individual certificate's "CRL Distribution Point" extension.
• Lifespan: Each CRL has its own validity period and is reissued by the CA at regular intervals.
• Limitations: CRLs can become very large, and downloading them can cause network load. This can also lead to security risks, as a client might accept a revoked certificate if it has an outdated copy of the list.
• Alternatives: Because of its limitations, other protocols like the Online Certificate Status Protocol (OCSP) have been developed and are sometimes preferred.

How OCSP works

• A client, like a web browser, needs to check the validity of a certificate it has received. Instead of downloading a large list of revoked certificates (a CRL), the client sends a request to an OCSP server (a "responder").
• The request includes information about the certificate in question.
• The OCSP responder checks the certificate's status against its records and sends back a digitally signed response.
• The response indicates whether the certificate is valid or has been revoked.

Key advantages

• Real-time status: Provides up-to-date information, enhancing security by limiting the window for malicious actors to use revoked certificates.
• Efficiency: Reduces server overhead compared to downloading large CRL files, as it only requires a request and response for a specific certificate.
• Reduced bandwidth: OCSP requests and responses are much smaller than CRLs, which saves bandwidth for both the client and the server.

Proposal

Implement certificate revocation validation that:

1. CRL Validation: Download and validate Certificate Revocation Lists from the URLs extracted from certificates
2. OCSP Support: Support Online Certificate Status Protocol as an alternative/additional revocation checking method
3. Real-time Validation: Perform revocation checks promptly whenever a certificate is attempted to be used for commit signing
4. Caching Strategy: Implement appropriate caching mechanisms for CRL data to balance security and performance

Customer Requirements

Based on customer feedback:

• CRL should be validated (or the list cross-checked) promptly whenever the certificate is attempted to be used
• The validation should happen in real-time during commit signature verification

Technical Considerations

• Determine appropriate caching duration for CRL data
• Handle network failures gracefully when CRL/OCSP endpoints are unavailable
• Consider performance impact of real-time revocation checking
• Ensure compatibility with existing X.509 certificate-based commit signing workflow

Related

This addresses a security requirement for enterprise customers using certificate-based commit signing in self-managed GitLab instances.