grpc/grpc-go · error
no DN found in certificate issuer
Error message
no DN found in certificate issuer
What it means
Returned by parseCertIssuerExt (security/advancedtls/crl.go:284) when parsing a CRL's Certificate Issuer extension and none of the GeneralName entries is a directoryName ([4]) form. The CRL revocation logic compares the issuer DN against the certificate, so without a DN it cannot reason about the entry and returns this error. The result surfaces as a RevocationUndetermined status.
Source
Thrown at security/advancedtls/crl.go:284
// otherName [0] OtherName,
// rfc822Name [1] IA5String,
// dNSName [2] IA5String,
// x400Address [3] ORAddress,
// directoryName [4] Name,
// ediPartyName [5] EDIPartyName,
// uniformResourceIdentifier [6] IA5String,
// iPAddress [7] OCTET STRING,
// registeredID [8] OBJECT IDENTIFIER }
if generalName.Tag == tagDirectoryName {
return generalName.Bytes, nil
}
}
// Conforming CRL issuers MUST include in this extension the
// distinguished name (DN) from the issuer field of the certificate that
// corresponds to this CRL entry.
// If we couldn't get a directoryName, we can't reason about this file so cert status is
// RevocationUndetermined.
return nil, errors.New("no DN found in certificate issuer")
}
// RFC 5280, 4.2.1.1
type authKeyID struct {
ID []byte `asn1:"optional,tag:0"`
}
// RFC5280, 5.2.5
// id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
// IssuingDistributionPoint ::= SEQUENCE {
// distributionPoint [0] DistributionPointName OPTIONAL,
// onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
// onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
// onlySomeReasons [3] ReasonFlags OPTIONAL,
// indirectCRL [4] BOOLEAN DEFAULT FALSE,
// onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
View on GitHub (pinned to 03255a9237)
Solutions
- Use a direct CRL (issued by the certificate's own CA) whose issuer is a proper DN, avoiding reliance on the Certificate Issuer extension.
- Regenerate the CRL so the issuer extension includes a directoryName GeneralName.
- Fetch the CRL from the authoritative distribution point rather than a possibly-altered mirror.
- If unavoidable, treat revocation as undetermined and fail closed/open per your security policy.
Example fix
// before: relying on an indirect CRL with URI-only issuer
// crlHelper.Verify -> error "no DN found in certificate issuer"
// after: use the direct CRL published by the issuing CA
verifyOpts := crllib.VerifyOptions{CRLProvider: directCRLProvider} Defensive patterns
Strategy: validation
Validate before calling
func hasDirectoryIssuer(exts []pkix.Extension) bool {
for _, e := range exts {
if oidCertIssuer.Equal(e.Id) && /* decode yields a directoryName */ true {
return true
}
}
return false
} Try / catch
status, err := crl.Verify(cert, opts)
if err != nil && strings.Contains(err.Error(), "no DN found") {
// switch to a direct CRL or fail closed
} Prevention
- Prefer direct CRLs issued by the cert's own CA.
- Validate CRL extensions with openssl before deployment.
- Treat undetermined revocation according to your security posture.
When it happens
Trigger: A CRL (typically an indirect CRL) whose Certificate Issuer extension uses only non-DN name forms such as a dNSName, uniformResourceIdentifier, or iPAddress; a malformed CRL with an empty issuer name list.
Common situations: Using an indirect CRL issued by a non-CA; a CA generating CRLs with non-standard issuer name encodings; corrupted or spec-non-compliant CRL files fetched from a CDN.
Understand the failure class
- SSL/TLS and certificate errors — how TLS handshakes and certificate validation fail.
Related errors
- trailing data after AKID extension
- trailing data after IssuingDistributionPoint extension
- 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/ba17047667eaafb2.
Report an issue: GitHub.