openbsd/src/lib/libcrypto/x509, branch master

Prior to this we substring matched and allowed a leading .

2026-04-13T17:04:23+00:00

on a SAN DNSname constraint. This is not correct, as with a DNSname constraint, it may exacly match or match zero or more additional components on the front of the candidte to match. Spotted by Haruto Kimura ok tb@ kenjiro@

Stop Delta CRL processing if a CRL number is misssing

2026-04-07T12:48:37+00:00

A malformed Delta CRL could cause a crash. Funnily enough the deserializer recognizes this and marks such a CRL as invalid, but nothing ever checks the EXFLAG_INVALID for CRLs. For certificates this would usually result in verification failure due to x509v3_cache_extensions() failing. This is only reachable if the X509_V_FLAG_USE_DELTAS is used, which only a handful of ports do, plus openssl(1) does if you use the undocumented -use_deltas flag. Reported by Igor Morgenstern to OpenSSL who then sat on this since Jan 8 and assigned CVE-2026-28388. ok jsing

x509v3.h: remove pointless #ifdef HEADER_CONF_H

2026-04-06T08:24:57+00:00

x509v3.h has included conf.h since June 20, 1999, OpenSSL commit ba404b5e, so HEADER_CONF_H has been defined since then. Also since then, CONF_VALUE (only available via conf.h) has been used outside of HEADER_CONF_H, making that #ifdef doubly pointless. ok bcook jsing kenjiro

Restore the previous behaviour with maximum verification depth.

2026-04-01T14:38:26+00:00

The maximum depth is not expected to include the leaf certificate - restore the decrement prior to checking, which means the previous behaviour is retained for the callback depth and the maximum depth. Reduce the maximum depth by one in order to avoid the overwrite that could previously occur. Thanks to anton@ for flagging the rust-openssl failure in regress. ok tb@

Fix an off-by-one error in the X.509 verifier depth checking.

2026-03-31T13:58:05+00:00

In x509_verify_build_chains(), ensure that we check the current depth against max_depth prior to turning it into a legacy-style depth index. Additionally, add a guard to x509_verify_chain_append() so that we avoid exceeding the maximum certs per chain, even if we fail to handle this correctly elsewhere. Also prevent the legacy callback from being able to override the maximum verification depth. The current off-by-one allows for a 4 byte overwrite to occur on heap allocated memory - this will likely trigger a crash on OpenBSD (but may go unnoticed elsewhere). This is only reachable if a TLS client is talking to a malicious server or if a TLS server has client certificate verification enabled - in both cases the verification depth also needs to be set to the maximum allowed value of 32. It is worth noting that many TLS clients/servers set the maximum verification depth to a value that is much less than the default. A libtls client or server uses a default depth of 6 and is not impacted in this configuration. Thanks to Calif.io in collaboration with Claude and Anthropic Research, for reporting the issue. ok tb@

replace buggy strncmp with strcmp found with clang-tidy

2026-02-07T17:12:47+00:00

Found the same fix from davidben in BoringSSL as well (https://boringssl-review.googlesource.com/c/boringssl/+/87927). OpenSSL appears to have accidentally changed the semantics here with the HAS_PREFIX macro, which appears to be incorrect. discussed w/ tb@ & beck@

x509_utl.c: zap two useless comments

2026-01-12T22:08:34+00:00

x509.h: annotate why X509_PKEY cannot be made opaque

2026-01-01T06:51:49+00:00

X509_NAME_ENTRY_set_data: remove redundant parentheses

2025-12-21T10:02:05+00:00

X509_NAME_ENTRY_set_data(): garbage collect unnecessary i

2025-12-21T09:44:45+00:00