A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_9 2026-03-28T11:33:33+00:00 2026-03-28T11:33:33+00:00 tb 2026-03-28T11:33:33+00:00 urn:sha1:cb80f3489708580ad1f1d4b027d1c0b23fa3f15a After the const sprinkling in OpenSSL 1.1, X509_get_{issuer,subject}_name() still returned a non-const pointer for unclear reasons. In OpenSSL 4, the return value also grew a const qualifier, so move the two "name" in tls_conninfo.c and the "subject_name" in tls_verify.c to const. They are only used for further processing by already const correct functions (at least as far as X509_NAME is concerned). ok djm jsing kenjiro 2024-12-10T08:40:30+00:00 tb 2024-12-10T08:40:30+00:00 urn:sha1:d3da05396af6da5d0c94da0425031aa4fd529ac9 There is currently no sane way of getting your hands on the common name or subject alternative name of the peer certificate from libtls. It is possible to extract it from the peer cert's PEM by hand, but that way lies madness. While the common name is close to being deprecated in the webpki, it is still the de facto standard to identify client certs. It would be nice to have a way to access the subject alternative names as well, but this is a lot more difficult to expose in a clean and sane C interface due to its multivaluedness. Initial diff from henning, with input from beck, jsing and myself henning and bluhm have plans of using this in syslogd. ok beck 2024-11-12T22:50:06+00:00 tb 2024-11-12T22:50:06+00:00 urn:sha1:fee58a01d3e38dbf53d13d5b43fb040439348421 A certificate must have a subject, so X509_get_subject_name() cannot return NULL on a correctly parsed certificate, even if the subject is empty (which is allowed). So if X509_get_subject_name() returns NULL, error instead of silently ignoring it in tls_check_common_name(). This is currently no issue. Where it matters, the match against the common name will fail later, so we fail closed anyway. ok jsing 2024-03-26T06:24:52+00:00 joshua 2024-03-26T06:24:52+00:00 urn:sha1:bd68c6e1694d8d4eb801f32889da4cdde0b3c311 This adds tls_config_error_code() and tls_error_code(), which will become public API at a later date. Additional error codes will be added in follow-up commits. ok jsing@ beck@ 2023-11-22T18:23:09+00:00 op 2023-11-22T18:23:09+00:00 urn:sha1:2c2a5b0696581cb264f5443d3825cea0e0382c75 from Ryan Kavanagh (rak [at] debian [dot] org), ok tb@ 2023-06-01T07:32:25+00:00 tb 2023-06-01T07:32:25+00:00 urn:sha1:fea987b2d1e959977f04e5f737991f6d06effae3 Default to having rv = -1 and explicitly goto done to set rv = 0. This matches other code better. ok jsing 2023-06-01T07:29:15+00:00 tb 2023-06-01T07:29:15+00:00 urn:sha1:db144b29c2c0d748705612fa7cb0ef4ecaa7667d X509_get_ext_d2i() (or rather X509V3_get_d2i()) can return NULL for various reasons. If it fails because the extension wasn't found, it sets *crit = -1. In any other case, e.g., the cert is bad or we ran out of memory in X509V3_EXT_d2i(), crit is set to something else, so we should actually error. ok jsing 2023-05-29T14:12:36+00:00 beck 2023-05-29T14:12:36+00:00 urn:sha1:ec96bb7cd92d9f4bd12be38b79757c0afc3a0e0f And some comment requests, from jsing@ ok jsing@ 2023-05-28T09:06:34+00:00 beck 2023-05-28T09:06:34+00:00 urn:sha1:ea823a8cf769df23c0d5d8896e76dea119ebbbe8 2023-05-28T09:02:01+00:00 beck 2023-05-28T09:02:01+00:00 urn:sha1:fc5c6fe4789b7726cefb7eef42e54c62ca51c1dc X509_NAME_get_text_by_NID is kind of a bad interface that we wish to make safer, and does not give us the visibility we really want here to detect hostile things. Instead call the lower level functions to do some better checking that should be done by X509_NAME_get_text_by_NID, but is not in the OpenSSL version. Specifically we will treat the input as hostile and fail if: 1) The certificate contains more than one CN in the subject. 2) The CN does not decode as UTF-8 3) The CN is of invalid length (must be between 1 and 64 bytes) 4) The CN contains a 0 byte 4) matches the existing logic, 1 and 2, and 3 are new checks. ok tb@