grpc/grpc-go · error

trailing data after IssuingDistributionPoint extension

Error message

trailing data after IssuingDistributionPoint extension

What it means

Returned by parseCRLExtensions (security/advancedtls/crl.go:341) when ASN.1 unmarshalling the Issuing Distribution Point extension leaves trailing bytes. Like the AKID check, leftover bytes mean the IDP extension is not a well-formed DER encoding. The check is at lines 336-342.

Source

Thrown at security/advancedtls/crl.go:341

		switch {
		case oidDeltaCRLIndicator.Equal(ext.Id):
			return nil, fmt.Errorf("delta CRLs unsupported")

		case oidAuthorityKeyIdentifier.Equal(ext.Id):
			var a authKeyID
			if rest, err := asn1.Unmarshal(ext.Value, &a); err != nil {
				return nil, fmt.Errorf("asn1.Unmarshal failed: %v", err)
			} else if len(rest) != 0 {
				return nil, errors.New("trailing data after AKID extension")
			}
			certList.authorityKeyID = a.ID

		case oidIssuingDistributionPoint.Equal(ext.Id):
			var dp issuingDistributionPoint
			if rest, err := asn1.Unmarshal(ext.Value, &dp); err != nil {
				return nil, fmt.Errorf("asn1.Unmarshal failed: %v", err)
			} else if len(rest) != 0 {
				return nil, errors.New("trailing data after IssuingDistributionPoint extension")
			}

			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 {

View on GitHub (pinned to 03255a9237)

Solutions

1. Re-download the CRL from its authoritative distribution point to eliminate transfer corruption.
2. Have the CA regenerate the CRL with a conformant IDP extension.
3. Inspect with openssl crl to confirm the extension decodes cleanly.
4. If the file is structurally invalid, replace it rather than retrying verification on it.

Example fix

# before: malformed IDP in /etc/crls/ca.crl
openssl crl -inform DER -in /etc/crls/ca.crl -text -noout # error

# after: refresh from source
curl -sfo /etc/crls/ca.crl https://ca.example.com/ca.crl
openssl crl -inform DER -in /etc/crls/ca.crl -text -noout # OK

var dp issuingDistributionPoint
rest, err := asn1.Unmarshal(idpExt.Value, &dp)
if err != nil || len(rest) != 0 {
    return fmt.Errorf("CRL has malformed IDP extension")
}

_, err := crl.Verify(cert, opts)
if err != nil && strings.Contains(err.Error(), "trailing data after IssuingDistributionPoint") {
    // re-fetch CRL, then retry
}

When it happens

Trigger: A CRL whose IDP extension value contains extra bytes after the SEQUENCE, or is otherwise non-canonical; a malformed CRL produced by a non-conformant CA or corrupted in transit.

Common situations: Buggy CA IDP encoding; CRL truncated/concatenated during download; CDN or proxy altering the bytes; non-minimal DER produced by older tooling.

Related errors

• trailing data after AKID extension
• no DN found in certificate issuer
• CRL only contains some certificate types
• indirect CRLs unsupported
• pemfile: certificate and key file must be in the same direct

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