Certificate verification fails if the certificate being verified does not contain the relevant extensions #11042

kajinamit · 2024-05-31T04:18:43Z

Problem description

I'm trying to verify the VCEK certificate published by AMD. According to the document VCEK is supposed to be verified by ARK (root certificate) and ASK (intermediate certificate).
However verification consistently fails because of Certificate is missing required extension.

>>> import datetime
>>>
>>> from cryptography import x509
>>> from cryptography.x509 import verification
>>>
>>> with open('certs/vcek.pem', 'rb') as f:
...     vcek = x509.load_pem_x509_certificate(f.read())
...
>>> with open('certs/ark.pem', 'rb') as f:
...     ark = x509.load_pem_x509_certificates(f.read())
...
>>> with open('certs/ask.pem', 'rb') as f:
...     ask = x509.load_pem_x509_certificates(f.read())
...
>>> store = verification.Store(ark)
>>> builder = verification.PolicyBuilder().store(store)
>>> builder = builder.time(datetime.datetime.now())
>>> verifier = builder.build_client_verifier()
>>> chain = verifier.verify(vcek, ask)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
cryptography.hazmat.bindings._rust.x509.VerificationError: validation failed: Other("Certificate is missing required extension")

I suspect "the missing required extension" is Authority Key Identifier (or Subject Key Identifier) . RFC5280 states that To facilitate certification path construction, this extension MUST appear in all conforming CA certificates while it also states that Conforming CAs MUST mark this extension as non-critical. I'm wondering if it makes sense that cryptography would ignore missing Subject Key Identifier field, if the field is supposed to be always non-critical.

Versions

Python 3.10.12 (built-in version in Ubuntu 22.04)
cryptography 43.0.0.dev1 (hash: ee4b371 )
pip 22.0.2
setuptools 59.6.0

Certificate contents

certs/vcek.pem

certs/ask.pem

certs/ark.pem

The text was updated successfully, but these errors were encountered:

kajinamit · 2024-05-31T04:21:57Z

The certificate can be verified by openssl

# openssl verify -CAfile certs/ark.pem -untrusted certs/ask.pem certs/vcek.pem
certs/vcek.pem: OK

or pyOpenSSL

>>> from OpenSSL import crypto
>>> with open('certs/vcek.pem', 'rb') as f:
...     vcek = crypto.load_certificate(crypto.FILETYPE_PEM, f.read())
...
>>> with open('certs/ark.pem', 'rb') as f:
...     ark = crypto.load_certificate(crypto.FILETYPE_PEM, f.read())
...
>>> with open('certs/ask.pem', 'rb') as f:
...     ask = crypto.load_certificate(crypto.FILETYPE_PEM, f.read())
...
>>> store = crypto.X509Store()
>>> store.add_cert(ark)
>>> store.add_cert(ask)
>>> ctx = crypto.X509StoreContext(store, vcek)
>>> ctx.verify_certificate()
>>>

kajinamit · 2024-05-31T04:25:11Z

OK it turned out the verification fails even with openssl when strict mode is enabled ...

# openssl verify -CAfile certs/ark.pem -untrusted certs/ask.pem -x509_strict certs/vcek.pem
OU = Engineering, C = US, L = Santa Clara, ST = CA, O = Advanced Micro Devices, CN = SEV-VCEK
error 85 at 0 depth lookup: Missing Authority Key Identifier
error certs/vcek.pem: verification failed

kajinamit · 2024-05-31T04:29:07Z

Since the issue is also detected by openssl, I've reported the issue in virtee/snpguest#57 (comment) .
We have checked a few certificates available in web but some of these do not contain these fields, actually.

reaperhulk · 2024-05-31T06:56:53Z

Our verifier currently is based on the WebPKI, which requires AKIs. This doesn't prohibit us having alternate verification options in the future (e.g., our client verifier), although some API discussion would be needed to determine what makes sense.

One concern I have is that it's not clear to me that AMD did the diligence to understand X.509 and generate proper certificates as opposed to just doing some quick empirical checks against existing implementations.

Separately, our error message would be more useful if it explained what required extensions were missing.

cc @woodruffw for when he's back from vacation 😄

woodruffw · 2024-06-06T20:53:20Z

Thanks for the ping @reaperhulk!

100% agreed about improving the error message; I can take a poke at that sometime in the coming days.

See also #10276 (comment) for a similar request (Intel SGX instead of AMD SEV, but also caused by profile variants).

woodruffw · 2024-06-26T01:59:30Z

Looping back: #11162 improved the extension error messages here.

lautip · 2024-08-21T09:46:23Z

I have this issue while using only cryptography. I made sure to have AKI in my root CA and certs (no intermediates in my application) and I still get this message "cryptography.hazmat.bindings._rust.x509.VerificationError: validation failed: Certificate is missing required extension" during verification.
Do you have an ETA for a release with improved extension error message(even a beta channel)?

alex · 2024-08-21T11:03:22Z

We're all volunteers working on an OSS project, no, we don't have an ETA.

mttkay · 2024-10-23T14:32:55Z

I am running against this too.

OpenSSL says that the end-entity certificate that is signed using my self-signed CA keys is correct even with x509 strict mode:

openssl verify -x509_strict -CAfile cc_root.crt leaf.crt

leaf.crt: OK

But our Python server says:

validation failed: Certificate is missing required extension"

Which one is missing then? Here are all extensions I used:

CA cert:

        X509v3 extensions:
            X509v3 Subject Key Identifier:
                82:BE:9A:E8:E5:47:83:EF:43:94:66:1C:A0:9C:43:75:D4:7B:43:D8
            X509v3 Authority Key Identifier:
                82:BE:9A:E8:E5:47:83:EF:43:94:66:1C:A0:9C:43:75:D4:7B:43:D8
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage:
                Certificate Sign

leaf cert:

        X509v3 extensions:
            X509v3 Key Usage:
                Digital Signature
            X509v3 Subject Key Identifier:
                62:74:0D:DE:C5:C0:52:2F:EB:C5:92:0E:EC:CA:D7:3A:E2:48:0C:DF
            X509v3 Authority Key Identifier:
                82:BE:9A:E8:E5:47:83:EF:43:94:66:1C:A0:9C:43:75:D4:7B:43:D8

mttkay · 2024-10-23T14:36:07Z

Is this the list of extensions cryptography considers to be required, and why?

cryptography/src/rust/cryptography-x509-verification/src/policy/extension.rs

Line 35 in 20c612e

let mut authority_information_access_seen = false;

alex · 2024-10-23T14:36:47Z

We currently require Subject Alt Names for all EE certs

…

On Wed, Oct 23, 2024, 10:33 AM Matthias Käppler ***@***.***> wrote: I am running against this too. OpenSSL says that the end-entity certificate that is signed using my self-signed CA keys is correct even with x509 strict mode: openssl verify -x509_strict -CAfile cc_root.crt leaf.crt leaf.crt: OK But our Python server says: validation failed: Certificate is missing required extension" Which one is missing then? Here are all extensions I used: CA cert: X509v3 extensions: X509v3 Subject Key Identifier: 82:BE:9A:E8:E5:47:83:EF:43:94:66:1C:A0:9C:43:75:D4:7B:43:D8 X509v3 Authority Key Identifier: 82:BE:9A:E8:E5:47:83:EF:43:94:66:1C:A0:9C:43:75:D4:7B:43:D8 X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: Certificate Sign leaf cert: X509v3 extensions: X509v3 Key Usage: Digital Signature X509v3 Subject Key Identifier: 62:74:0D:DE:C5:C0:52:2F:EB:C5:92:0E:EC:CA:D7:3A:E2:48:0C:DF X509v3 Authority Key Identifier: 82:BE:9A:E8:E5:47:83:EF:43:94:66:1C:A0:9C:43:75:D4:7B:43:D8 — Reply to this email directly, view it on GitHub <#11042 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBBN2G3ZFZXAJRGP2IDZ46XS5AVCNFSM6AAAAABISCKMK6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZSGQZDKNRQHA> . You are receiving this because you commented.Message ID: ***@***.***>

woodruffw · 2024-10-23T14:51:05Z

To add on to what @alex said: SANs are required because the current validator is a CABF validator, meaning it uses the rules for X.509 certificates on the web PKI. CABF says that SANs are required, so that requirement is enforced.

(OpenSSL's strict enforcement mode is insufficient: they don't implement all of the CABF rules and are unlikely to do so, since it'd be a major breaking change.)

mttkay · 2024-10-23T15:39:02Z

Thank you @alex @woodruffw, adding the SAN extension fixed the problem for me. Thanks for explaining the rationale as well, I am not overly familiar with the PKIX space so this is helpful.

woodruffw mentioned this issue Jun 26, 2024

FR: Allow clients to set extension policies for x.509 verification #11165

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Certificate verification fails if the certificate being verified does not contain the relevant extensions #11042

Certificate verification fails if the certificate being verified does not contain the relevant extensions #11042

kajinamit commented May 31, 2024 •

edited

Loading

kajinamit commented May 31, 2024

kajinamit commented May 31, 2024

kajinamit commented May 31, 2024

reaperhulk commented May 31, 2024

woodruffw commented Jun 6, 2024

woodruffw commented Jun 26, 2024

lautip commented Aug 21, 2024

alex commented Aug 21, 2024

mttkay commented Oct 23, 2024

mttkay commented Oct 23, 2024

alex commented Oct 23, 2024 via email

woodruffw commented Oct 23, 2024

mttkay commented Oct 23, 2024

Certificate verification fails if the certificate being verified does not contain the relevant extensions #11042

Certificate verification fails if the certificate being verified does not contain the relevant extensions #11042

Comments

kajinamit commented May 31, 2024 • edited Loading

Problem description

Versions

Certificate contents

kajinamit commented May 31, 2024

kajinamit commented May 31, 2024

kajinamit commented May 31, 2024

reaperhulk commented May 31, 2024

woodruffw commented Jun 6, 2024

woodruffw commented Jun 26, 2024

lautip commented Aug 21, 2024

alex commented Aug 21, 2024

mttkay commented Oct 23, 2024

mttkay commented Oct 23, 2024

alex commented Oct 23, 2024 via email

woodruffw commented Oct 23, 2024

mttkay commented Oct 23, 2024

kajinamit commented May 31, 2024 •

edited

Loading