grpc/grpc-go · error

authority key identifier extension missing

Error message

authority key identifier extension missing

What it means

Returned by parseCRLExtensions (crl.go:359) after iterating all CRL extensions if no Authority Key Identifier (AKID) was found. RFC 5280 section 5.2.1 mandates that conforming CRL issuers include the AKID extension in every CRL, and gRPC relies on it to match the CRL issuer to a certificate in the peer chain (see verifyCRL at crl.go:377). Without it, the validator cannot safely bind the CRL to an issuer and refuses it.

Source

Thrown at security/advancedtls/crl.go:360

			}

			if dp.OnlyContainsUserCerts || dp.OnlyContainsCACerts || dp.OnlyContainsAttributeCerts {
				return nil, errors.New("CRL only contains some certificate types")
			}
			if dp.IndirectCRL {
				return nil, errors.New("indirect CRLs unsupported")
			}
			if dp.OnlySomeReasons.BitLength != 0 {
				return nil, errors.New("onlySomeReasons unsupported")
			}

		case ext.Critical:
			return nil, fmt.Errorf("unsupported critical extension: %v", ext.Id)
		}
	}

	if len(certList.authorityKeyID) == 0 {
		return nil, errors.New("authority key identifier extension missing")
	}
	return certList, nil
}

func verifyCRL(crl *CRL, chain []*x509.Certificate) error {
	// RFC5280, 6.3.3 (f) Obtain and validate the certification path for the issuer of the complete CRL
	// We intentionally limit our CRLs to be signed with the same certificate path as the certificate
	// so we can use the chain from the connection.

	for _, c := range chain {
		// Use the key where the subject and KIDs match.
		// This departs from RFC4158, 3.5.12 which states that KIDs
		// cannot eliminate certificates, but RFC5280, 5.2.1 states that
		// "Conforming CRL issuers MUST use the key identifier method, and MUST
		// include this extension in all CRLs issued."
		// So, this is much simpler than RFC4158 and should be compatible.
		if bytes.Equal(c.SubjectKeyId, crl.authorityKeyID) && bytes.Equal(c.RawSubject, crl.rawIssuer) {
			// RFC5280, 6.3.3 (f) Key usage and cRLSign bit.

View on GitHub (pinned to 03255a9237)

Solutions

1. Re-fetch the CRL from the CA's distribution point; if the issue persists, regenerate the CRL with OpenSSL `ca -gencrl` from a CA cert that itself has a Subject Key Identifier.
2. Ensure the issuing CA certificate has a Subject Key Identifier (SKID), since most CAs copy AKID from the issuer's SKID.
3. Validate the CRL with `openssl crl -in crl.pem -noout -text` and confirm an 'Authority Key Identifier' section is present before loading it.

Example fix

// before: CRL has no AKID extension -> rejected
// after: regenerate CRL from a CA cert that has Subject Key Identifier
//   openssl ca -gencrl -out crl.pem
// Verify AKID present:
//   openssl crl -in crl.pem -noout -text | grep -A2 'Authority Key'

import "crypto/x509"

func crlHasAKID(c *x509.RevocationList) bool {
    if c == nil { return false }
    // Authority Key Identifier oid 2.5.29.35
    oidAKI := []int{2, 5, 29, 35}
    for _, ext := range c.Extensions {
        if len(ext.Id) == len(oidAKI) {
            match := true
            for i := range oidAKI {
                if ext.Id[i] != oidAKI[i] { match = false; break }
            }
            if match { return true }
        }
    }
    return false
}

func isConformantCRL(c *x509.RevocationList) bool {
    return c != nil && crlHasAKID(c)
}

When it happens

Trigger: Loading a CRL that lacks the Authority Key Identifier extension (oid 2.5.29.35) into advancedtls revocation checking. The loop never hits the oidAuthorityKeyIdentifier case, so certList.authorityKeyID stays empty and the post-loop check fails.

Common situations: Legacy or non-conformant CA that omits the AKID extension; a manually crafted/edited CRL; a CA whose newer CRLs dropped the field due to a misconfiguration; some Windows-based or older OpenSSL CAs historically produced AKID-less CRLs.

Related errors

• onlySomeReasons unsupported
• extractCRLIssuer: invalid ASN.1 encoding
• no DN found in certificate issuer
• trailing data after AKID extension
• trailing data after IssuingDistributionPoint extension

AI-assisted analysis of grpc/grpc-go@03255a9237 (2026-08-07). Data as JSON: /api/errors/c1ad59e448ac4dfb. Report an issue: GitHub.