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

  1. Use a direct CRL (issued by the certificate's own CA) whose issuer is a proper DN, avoiding reliance on the Certificate Issuer extension.
  2. Regenerate the CRL so the issuer extension includes a directoryName GeneralName.
  3. Fetch the CRL from the authoritative distribution point rather than a possibly-altered mirror.
  4. 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

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

Related errors


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