Certificates with an empty extensions sequence are rejected

[main--]

Example:

-----BEGIN CERTIFICATE-----
MIICVjCCAT6gAwIBAgIBQjANBgkqhkiG9w0BAQsFADAsMQswCQYDVQQGEwJVUzEM
MAoGA1UECgwDT3JnMQ8wDQYDVQQDDAZyb290Q0EwHhcNMjUwMzI2MjIxODI1WhcN
MjYwMzI2MjIxODI1WjAxMQswCQYDVQQGEwJVUzEMMAoGA1UECgwDT3JnMRQwEgYD
VQQDDAtleGFtcGxlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsHpY
Glfbynn6DNH+k4JIBP1B/ZZmwP63K2R2zplArmWo/aEmYJ27VPsU65VGkWARWSiU
n6Ja22sP0I5Y3Q0ueFe0UMTTk+pk4uu6Hakfp+Pf23WgIdGUPFb3upW1S7sGa1BU
C3/Ud+4TAR8F98Ro8/yWZxqJU3JehHGNs4C1dCsCAwEAAaMCMAAwDQYJKoZIhvcN
AQELBQADggEBAF2fRBByoDts9hE1hGcVN5x0BTu5aQDhxFC3wy6gm31PBOLQYI9z
fOzaOMoh9bf2aCOGRIBBXQEhAwbEFDbuO6PiN0WPrgTo4nB3aBh6VVFEuHtYJhmY
A1YDs5ELG20fHRxIpKkBtd6uUPHBjFuWBI7uZkoiCyT4EQYqQcJPk6QYcPpu2hq1
tBbhJV/BDapKAWt3TB088h60S72MmJCErsjkOVl6XLzl08gJBWtntyXvsS1B0K1X
1mH3u0UxALL484R9wUZ6Ja6U+WDxbkczps6UctOKbIzJHaC8ElPZfdmRtftL2Arn
cHgliXZb6lQCN5EmD9hohd+b/iSP2TXIj/U=
-----END CERTIFICATE-----

The certificate has an empty extensions sequence (A3 02 30 00). This is different from a certificate where the extensions sequence is missing altogether, which was fixed in #34. The certificate is rejected because of the way the loop in nested_of_mut is written: the inner loop first attempts to decode an item, and only then checks outer.at_end(). If there are no items, decoding the first item fails, so the certificate is rejected.

webpki/src/der.rs

Lines 309 to 325 in ab50614

	pub(crate) fn nested_of_mut<'a>(
	input: &mut untrusted::Reader<'a>,
	outer_tag: Tag,
	inner_tag: Tag,
	error: Error,
	mut decoder: impl FnMut(&mut untrusted::Reader<'a>) -> Result<(), Error>,
	) -> Result<(), Error> {
	nested(input, outer_tag, error.clone(), |outer| {
	loop {
	nested(outer, inner_tag, error.clone(), |inner| decoder(inner))?;
	if outer.at_end() {
	break;
	}
	}
	Ok(())
	})
	}

See also openssl/openssl#20877 for a real-world example of such certificates (and a possible explanation for why they are quite rare).

[djc]

These are explicitly ruled out as valid by RFC 5280 in 4.1.2.9:

If present, this field is a SEQUENCE of one or more certificate extensions. The format and content of certificate extensions in the Internet PKI are defined in Section 4.2.

Why can't you fix the certificate?

[main--]

I can see your point. The reason I can't just go and fix the certificate is that in the case where I hit this issue, the certificate is generated by Google Cloud SQL. Certificates with empty extensions are currently accepted by (at least) openssl, gnutls and schannel (probably more, those three are just what I was able to quickly test). Rustls is the only TLS implementation I am aware of that chooses the strict interpretation of the RFC, where such certificates are treated as invalid.

In fact, it appears to be the case in openssl that when disabling the subjectKeyIdentifier and authorityKeyIdentifier extensions (which are otherwise added by default) a certificate with an empty extensions sequence is generated. Or in other words: an extensionless V3 certificate generated by openssl would, to my understanding, always carry this empty extension sequence.

So while I can definitely understand that rejecting certificates, which by a strict reading of the RFC would be invalid, sounds less like a bug and more like intended behavior, the reality is that major TLS implementations out there generate and accept these certificates, while applications using rustls break with a puzzling BadEncoding error - on a certificate that, according to all the other tools, is encoded just fine.

[cpu]

the certificate is generated by Google Cloud SQL

Are you a customer? Have you opened a bug report with Google?

(and a possible explanation for why they are quite rare).

I don't think you've presented a compelling case for why we should change webpki to relax its compliance to the relevant standards. As you report, the misencoding is rare (and should be straight forward to fix at its source). AIUI certificates with this encoding error would also be subject to revocation in the Web PKI (which, as the name implies, this crate is primarily focused on).

Please consider the arguments from https://alexgaynor.net/2025/mar/25/postels-law-and-the-three-ring-circus/ - I think it makes a strong case for why we shouldn't relax our stance here.

[main--]

I am neither a customer to Google nor to the cable modems from openssl/openssl#20877. I am simply trying to help other people and save them the hours I spent debugging this.

Please consider the arguments from https://alexgaynor.net/2025/mar/25/postels-law-and-the-three-ring-circus/ - I think it makes a strong case for why we shouldn't relax our stance here.

And I think you're wrong about that. As much as I agree with this piece - everything that it describes and warns against has already happened here. Major implementations accept and produce these certificates. The deviance has normalized, and now the new implementation is faced with the impossible choice of whether to accept it. If the problem was solvable with a simple "no", then we would have overcome it long ago. Other implementations being lax about this in the past has brought us to the point where today

new implementations will need to [...] iteratively make themselves more lax as users attempt to use them in real world scenarios

I believe the post is arguing for a world where the certificates in question were never issued in the first place because strict implementations never accepted them to begin with. Sadly this is not how things went. That I am now asking you to make your implementation more lax is merely a consequence of this problem, and not the cause. Pandora's box is open, and as much as you and me both agree that these certificates should not exist, we won't be able to will them out of existence.

[ctz]

It's a complete guess, but I suspect this will be golang/go#52319 coupled with the fact that Google Cloud SQL generates per-instance 10-year certs. Golang's decoder obviously still retains the matching bug. It's not a great situation.

[ctz]

This was fixed in #342 / #336

[djc]

(This was released in 0.103.2.)