grpc/grpc-go · warning

no DN found in certificate issuer

Error message

no DN found in certificate issuer

What it means

Returned by parseCertIssuerExt when parsing the CRL entry's Certificate Issuer extension (RFC 5280 5.3.3, only present in indirect CRLs). The code walks the GeneralNames sequence looking for a directoryName [4] entry to use as the issuer DN; if none is present, the library cannot correlate the entry to a certificate and the cert's revocation status is treated as undetermined.

Solutions

1. Regenerate the CRL so the Certificate Issuer extension includes a directoryName [4] entry matching the certificate's issuer DN, or stop using indirect CRLs entirely.
2. Switch to a direct CRL (issuer DN in the top-level tbsCertList.issuer matches the cert issuer).
3. If the CRL is from an upstream CA you don't control, request a direct-CRL variant or fall back to OCSP for revocation checks.

Treat the error as revocation status RevocationUndetermined (the library already does this internally); do not fail the handshake hard. Configure the advancedtls verifier to decide undetermined as allow or deny per your security posture.

When it happens

Trigger: A CRL contains per-entry Certificate Issuer extensions (i.e. it is structured as an indirect CRL) but the issuer extension lists only non-directoryName GeneralNames (e.g. DNSName, URI) and no [4] directoryName. Encountered during revocation checking of a peer cert against such a CRL.

Common situations: An indirect-CRL-shaped revocation list from a CA that uses URI/DNS-based issuer naming instead of DNs. Compatibility mismatch: the CRL was generated by tooling that omits the directoryName variant. grpc-go's CRL support is intentionally narrow (see the indirect-CRL rejection elsewhere) so non-DN issuers are not handled.

Understand the failure class

• SSL/TLS and certificate errors — how TLS handshakes and certificate validation fail.

Related errors

• extractCRLIssuer: invalid ASN.1 encoding
• indirect CRLs unsupported
• trailing data after AKID extension
• trailing data after IssuingDistributionPoint extension
• authority key identifier extension missing

AI-assisted analysis of grpc/grpc-go@0c51461d27 (2026-08-11). Data as JSON: /api/errors/ba17047667eaafb2. Report an issue: GitHub.

Appendix: 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 0c51461d27)