rule_id: codeguard-1-digital-certificates
When you encounter data that appears to be an X.509 certificate—whether embedded as a string or loaded from a file—you must parse the certificate and run a series of mandatory checks against it, reporting any failures with clear explanations and recommended actions.
1. How to Identify Certificate Data
Actively scan for certificate data using the following heuristics:
PEM-Encoded Strings: Identify multi-line string literals or constants that begin with -----BEGIN CERTIFICATE----- and end with -----END CERTIFICATE-----.
File Operations: Pay close attention to file read operations on files with common certificate extensions, such as .pem, .crt, .cer, and .der.
Library Function Calls: Recognize the usage of functions from cryptographic libraries used to load or parse certificates (e.g., OpenSSL's PEM_read_X509, Python's cryptography.x509.load_pem_x509_certificate, Java's CertificateFactory).
2. Mandatory Sanity Checks
Once certificate data is identified, you must perform the following validation steps and report the results.
Check 1: Expiration Status
Condition: The certificate's notAfter (expiration) date is before June 23, 2025.
Severity: CRITICAL VULNERABILITY
Report Message: This certificate expired on [YYYY-MM-DD]. It is no longer valid and will be rejected by clients, causing connection failures. It must be renewed and replaced immediately.
Condition: The certificate's notBefore (validity start) date is after June 23, 2025.
Severity: Warning
Report Message: This certificate is not yet valid. Its validity period begins on [YYYY-MM-DD].
Check 2: Public Key Strength
Condition: The public key algorithm or size is weak.
- Weak Keys: RSA keys with a modulus smaller than 2048 bits. Elliptic Curve (EC) keys using curves with less than a 256-bit prime modulus (e.g.,
secp192r1, P-192, P-224).
Severity: High-Priority Warning
Report Message: The certificate's public key is cryptographically weak ([Algorithm], [Key Size]). Keys of this strength are vulnerable to factorization or discrete logarithm attacks. The certificate should be re-issued using at least an RSA 2048-bit key or an ECDSA key on a P-256 (or higher) curve.
Check 3: Signature Algorithm
Condition: The algorithm used to sign the certificate is insecure.
- Insecure Algorithms: Any signature algorithm using MD5 or SHA-1 (e.g.,
md5WithRSAEncryption, sha1WithRSAEncryption).
Severity: High-Priority Warning
Report Message: The certificate is signed with the insecure algorithm '[Algorithm]'. This makes it vulnerable to collision attacks, potentially allowing for certificate forgery. It must be re-issued using a signature based on the SHA-2 family (e.g., sha256WithRSAEncryption).
Check 4: Issuer Type (Self-Signed Check)
Condition: The certificate's Issuer and Subject fields are identical.
Severity: Informational
Report Message: This is a self-signed certificate. Ensure this is intentional and only used for development, testing, or internal services where trust is explicitly configured. Self-signed certificates should never be used for public-facing production systems as they will not be trusted by browsers or standard clients.
3. Actionable Examples
Your feedback should be direct and easy to understand.
Example 1: Flagging an Expired, In-line Certificate
Code Snippet:
# Certificate for connecting to legacy_service
LEGACY_CERT = """
-----BEGIN CERTIFICATE-----
MIIC... (data for a certificate that expired on 2024-12-01) ...
-----END CERTIFICATE-----
"""
Your Analysis and Report:
CRITICAL VULNERABILITY: The certificate stored in the LEGACY_CERT variable is invalid.
Reason: It expired on 2024-12-01.
Impact: Any TLS connection attempting to use this certificate will fail.
Action: This certificate must be renewed and the variable updated with the new PEM data immediately.
Example 2: Flagging a Weak Key in a Loaded Certificate
Code Snippet:
// Load the server certificate from disk
cert, err := tls.LoadX509KeyPair("server.crt", "server.key")
// Assume server.crt contains a 1024-bit RSA key.
Your Analysis and Report:
High-Priority Warning: The certificate being loaded from server.crt is using a weak public key.
Reason: It uses an RSA key with a 1024-bit modulus.
Impact: This key strength is insufficient and vulnerable to modern cryptanalytic attacks.
Action: A new certificate and key must be generated with at least a 2048-bit RSA key or a modern elliptic curve.
You must always explain how this rule was applied and why it was applied.
1---2name: rule-id-codeguard-1-digital-certificates3description: When you encounter data that appears to be an X.509 certificate—whether embedded as a string or loaded from a file—you must parse the certificate and run a series of mandatory checks against it, reporting any failures…4---56rule_id: codeguard-1-digital-certificates78When you encounter data that appears to be an X.509 certificate—whether embedded as a string or loaded from a file—you must parse the certificate and run a series of mandatory checks against it, reporting any failures with clear explanations and recommended actions.910### 1. How to Identify Certificate Data1112Actively scan for certificate data using the following heuristics:1314- PEM-Encoded Strings: Identify multi-line string literals or constants that begin with `-----BEGIN CERTIFICATE-----` and end with `-----END CERTIFICATE-----`.1516- File Operations: Pay close attention to file read operations on files with common certificate extensions, such as `.pem`, `.crt`, `.cer`, and `.der`.1718- Library Function Calls: Recognize the usage of functions from cryptographic libraries used to load or parse certificates (e.g., OpenSSL's `PEM_read_X509`, Python's `cryptography.x509.load_pem_x509_certificate`, Java's `CertificateFactory`).192021### 2. Mandatory Sanity Checks2223Once certificate data is identified, you must perform the following validation steps and report the results.2425#### Check 1: Expiration Status2627- Condition: The certificate's `notAfter` (expiration) date is before June 23, 2025.2829- Severity: CRITICAL VULNERABILITY3031- Report Message: `This certificate expired on [YYYY-MM-DD]. It is no longer valid and will be rejected by clients, causing connection failures. It must be renewed and replaced immediately.`3233- Condition: The certificate's `notBefore` (validity start) date is after June 23, 2025.3435- Severity: Warning3637- Report Message: `This certificate is not yet valid. Its validity period begins on [YYYY-MM-DD].`383940#### Check 2: Public Key Strength4142- Condition: The public key algorithm or size is weak.4344 - Weak Keys: RSA keys with a modulus smaller than 2048 bits. Elliptic Curve (EC) keys using curves with less than a 256-bit prime modulus (e.g., `secp192r1`, `P-192`, `P-224`).4546- Severity: High-Priority Warning4748- Report Message: `The certificate's public key is cryptographically weak ([Algorithm], [Key Size]). Keys of this strength are vulnerable to factorization or discrete logarithm attacks. The certificate should be re-issued using at least an RSA 2048-bit key or an ECDSA key on a P-256 (or higher) curve.`495051#### Check 3: Signature Algorithm5253- Condition: The algorithm used to sign the certificate is insecure.5455 - Insecure Algorithms: Any signature algorithm using MD5 or SHA-1 (e.g., `md5WithRSAEncryption`, `sha1WithRSAEncryption`).5657- Severity: High-Priority Warning5859- Report Message: `The certificate is signed with the insecure algorithm '[Algorithm]'. This makes it vulnerable to collision attacks, potentially allowing for certificate forgery. It must be re-issued using a signature based on the SHA-2 family (e.g., sha256WithRSAEncryption).`606162#### Check 4: Issuer Type (Self-Signed Check)6364- Condition: The certificate's `Issuer` and `Subject` fields are identical.6566- Severity: Informational6768- Report Message: `This is a self-signed certificate. Ensure this is intentional and only used for development, testing, or internal services where trust is explicitly configured. Self-signed certificates should never be used for public-facing production systems as they will not be trusted by browsers or standard clients.`697071### 3. Actionable Examples7273Your feedback should be direct and easy to understand.7475Example 1: Flagging an Expired, In-line Certificate7677- Code Snippet:7879 ```80 # Certificate for connecting to legacy_service81 LEGACY_CERT = """82 -----BEGIN CERTIFICATE-----83 MIIC... (data for a certificate that expired on 2024-12-01) ...84 -----END CERTIFICATE-----85 """86 ```8788- Your Analysis and Report:8990 > CRITICAL VULNERABILITY: The certificate stored in the `LEGACY_CERT` variable is invalid.91 >92 > - Reason: It expired on 2024-12-01.93 >94 > - Impact: Any TLS connection attempting to use this certificate will fail.95 >96 > - Action: This certificate must be renewed and the variable updated with the new PEM data immediately.97 >9899100Example 2: Flagging a Weak Key in a Loaded Certificate101102- Code Snippet:103104 ```105 // Load the server certificate from disk106 cert, err := tls.LoadX509KeyPair("server.crt", "server.key")107 // Assume server.crt contains a 1024-bit RSA key.108 ```109110- Your Analysis and Report:111112 > High-Priority Warning: The certificate being loaded from `server.crt` is using a weak public key.113 >114 > - Reason: It uses an RSA key with a 1024-bit modulus.115 >116 > - Impact: This key strength is insufficient and vulnerable to modern cryptanalytic attacks.117 >118 > - Action: A new certificate and key must be generated with at least a 2048-bit RSA key or a modern elliptic curve.119120121You must always explain how this rule was applied and why it was applied.
tools-only