aboutsummaryrefslogtreecommitdiffstats
path: root/src/net/validator.c
Commit message (Collapse)AuthorAgeFilesLines
* [crypto] Fix debug name for empty certificate chain validatorsMichael Brown2024-08-141-2/+4
| | | | | | | | | | | | | | | | | An attempt to use a validator for an empty certificate chain will correctly fail the overall validation with the "empty certificate chain" error propagated from x509_auto_append(). In a debug build, the call to validator_name() will attempt to call x509_name() on a non-existent certificate, resulting in garbage in the debug message. Fix by checking for the special case of an empty certificate chain. This issue does not affect non-debug builds, since validator_name() is (as per its description) called only for debug messages. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow for multiple cross-signed certificate download attemptsMichael Brown2024-02-151-100/+227
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Certificates issued by Let's Encrypt have two options for their chain of trust: the chain can either terminate in the self-signed ISRG Root X1 root certificate, or in an intermediate ISRG Root X1 certificate that is signed in turn by the self-signed DST Root CA X3 root certificate. This is a historical artifact: when Let's Encrypt first launched as a project, the chain ending in DST Root CA X3 was used since existing clients would not have recognised the ISRG Root X1 certificate as a trusted root certificate. The DST Root CA X3 certificate expired in September 2021, and so is no longer trusted by clients (such as iPXE) that validate the expiry times of all certificates in the certificate chain. In order to maintain usability of certificates on older Android devices, the default certificate chain provided by Let's Encrypt still terminates in DST Root CA X3, even though that certificate has now expired. On newer devices which include ISRG Root X1 as a trusted root certificate, the intermediate version of ISRG Root X1 in the certificate chain is ignored and validation is performed as though the chain had terminated in the self-signed ISRG Root X1 root certificate. On older Android devices which do not include ISRG Root X1 as a trusted root certificate, the validation succeeds since Android chooses to ignore expiry times for root certificates and so continues to trust the DST Root CA X3 root certificate. This backwards compatibility hack unfortunately breaks the cross- signing mechanism used by iPXE, which assumes that the certificate chain will always terminate in a non-expired root certificate. Generalise the validator's cross-signed certificate download mechanism to walk up the certificate chain in the event of a failure, attempting to find a replacement cross-signed certificate chain starting from the next level up. This allows the validator to step over the expired (and hence invalidatable) DST Root CA X3 certificate, and instead download the cross-signed version of the ISRG Root X1 certificate. This generalisation also gives us the ability to handle servers that provide a full certificate chain including their root certificate: iPXE will step over the untrusted public root certificate and attempt to find a cross-signed version of it instead. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add x509_is_self_signed() helper functionMichael Brown2024-02-151-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [x509] Make root of trust a reference-counted structureMichael Brown2020-12-091-1/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [x509] Record root of trust used when validating a certificateMichael Brown2020-12-081-3/+8
| | | | | | | | | | | | | Record the root of trust used at the point that a certificate is validated, redefine validation as checking a certificate against a specific root of trust, and pass an explicit root of trust when creating a TLS connection. This allows a custom TLS connection to be used with a custom root of trust, without causing any validated certificates to be treated as valid for normal purposes. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Display cross-certificate and OCSP status messagesMichael Brown2019-03-071-8/+62
| | | | | | | | | | | | | TLS connections will almost always create background connections to perform cross-signed certificate downloads and OCSP checks. There is currently no direct visibility into which checks are taking place, which makes troubleshooting difficult in the absence of either a packet capture or a debug build. Use the job progress message buffer to report the current cross-signed certificate download or OCSP status check, where applicable. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Use x509_name() in validator debug messagesMichael Brown2019-03-071-37/+68
| | | | | | | Display a human-readable certificate name in validator debug messages wherever possible. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ocsp] Centralise test for whether or not an OCSP check is requiredMichael Brown2018-03-181-2/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Fail fast if cross-certificate source is emptyLadi Prosek2017-09-241-0/+5
| | | | | | | | | | | | In fully self-contained deployments it may be desirable to build iPXE with an empty CROSSCERT source to avoid talking to external services. Add an explicit check for this case and make validator_start_download fail immediately if the base URI is empty. Signed-off-by: Ladi Prosek <lprosek@redhat.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Generalise X.509 "valid" field to a "flags" fieldMichael Brown2016-08-251-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow cross-certificate source to be configured at build timeMichael Brown2016-03-241-1/+2
| | | | | | | | | Provide a build option CROSSCERT in config/crypto.h to allow the default cross-signed certificate source to be configured at build time. The ${crosscert} setting may still be used to reconfigure the cross-signed certificate source at runtime. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xferbuf] Generalise to handle umalloc()-based buffersMichael Brown2015-07-221-2/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [base64] Add buffer size parameter to base64_encode() and base64_decode()Michael Brown2015-04-241-1/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [legal] Relicense files under GPL2_OR_LATER_OR_UBDLMichael Brown2015-03-021-1/+5
| | | | | | | Relicense files for which I am the sole author (as identified by util/relicense.pl). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Generalise X.509 cache to a full certificate storeMichael Brown2014-03-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Expand the concept of the X.509 cache to provide the functionality of a certificate store. Certificates in the store will be automatically used to complete certificate chains where applicable. The certificate store may be prepopulated at build time using the CERT=... build command line option. For example: make bin/ipxe.usb CERT=mycert1.crt,mycert2.crt Certificates within the certificate store are not implicitly trusted; the trust list is specified using TRUST=... as before. For example: make bin/ipxe.usb CERT=root.crt TRUST=root.crt This can be used to embed the full trusted root certificate within the iPXE binary, which is potentially useful in an HTTPS-only environment in which there is no HTTP server from which to automatically download cross-signed certificates or other certificate chain fragments. This usage of CERT= extends the existing use of CERT= to specify the client certificate. The client certificate is now identified automatically by checking for a match against the private key. For example: make bin/ipxe.usb CERT=root.crt,client.crt TRUST=root.crt KEY=client.key Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Remove dynamically-allocated storage for certificate OCSP URIMichael Brown2014-03-251-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Remove dynamically-allocated storage for certificate nameMichael Brown2014-03-251-1/+1
| | | | | | | | | | | | | | iPXE currently allocates a copy the certificate's common name as a string. This string is used by the TLS and CMS code to check certificate names against an expected name, and also appears in debugging messages. Provide a function x509_check_name() to centralise certificate name checking (in preparation for adding subjectAlternativeName support), and a function x509_name() to provide a name to be used in debugging messages, and remove the dynamically allocated string. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Force settings into alphabetical order within sectionsMichael Brown2013-12-051-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Explicitly separate the concept of a completed fetched settingMichael Brown2013-12-051-10/+2
| | | | | | | | | | The fetch_setting() family of functions may currently modify the definition of the specified setting (e.g. to add missing type information). Clean up this interface by requiring callers to provide an explicit buffer to contain the completed definition of the fetched setting, if required. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Fix unused-but-set variable warningMichael Brown2012-05-231-2/+0
| | | | | Reported-by: Brandon Penglase <bpenglase-ipxe@spaceservices.net> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Automatically perform OCSP checks when applicableMichael Brown2012-05-221-68/+195
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Include "?subject=" in cross-signed certificate URIMichael Brown2012-05-091-3/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Reduce standard debugging outputMichael Brown2012-05-091-4/+4
| | | | | | | | X.509 certificate processing currently produces an overwhelming amount of debugging information. Move some of this from DBGLVL_LOG to DBGLVL_EXTRA, to make the output more manageable. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Automatically download cross-signed certificatesMichael Brown2012-05-081-11/+284
| | | | | | | | Automatically attempt to download any required cross-signing certificates from http://ca.ipxe.org/auto, in order to enable the use of standard SSL certificates issued by public CAs. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add asynchronous certificate validatorMichael Brown2012-05-081-0/+178
To allow for automatic download of cross-signing certificates and for OCSP, the validation of certificates must be an asynchronous process. Create a stub validator which uses a job-control interface to report the result of certificate validation. Signed-off-by: Michael Brown <mcb30@ipxe.org>