[crypto] Fix parsing of OCSP responder ID key hash
We currently compare the entirety of the KeyHash object (including the
ASN.1 tag and length byte) against the raw SHA-1 hash of the
certificate's public key. This causes OCSP validation to fail for any
responses which identify the responder by key hash rather than by
name, and hence prevents the use of X.509 certificates where any
certificate in the chain has an OCSP responder which chooses to
identify itself via its key hash.
Fix by adding the missing asn1_enter() required to enter the ASN.1
octet string containing the key hash.
Also add a corresponding test case including an OCSP response where
the responder is identified by key hash, to ensure that this
functionality cannot be broken in future.
Debugged-by: Brian Rak <brak@gameservers.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Generalise X.509 cache to a full certificate store
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 name
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>
[ocsp] Handle OCSP responses that don't provide certificates
Certificate authorities are not required to send the certificate used
to sign the OCSP response if the response is signed by the original
issuer.
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add support for parsing of URIs containing literal IPv6 addresses
(e.g. "http://[fe80::69ff:fe50:5845%25net0]/boot.ipxe").
Duplicate URIs by directly copying the relevant fields, rather than by
formatting and reparsing a URI string. This relaxes the requirements
on the URI formatting code and allows it to focus on generating
human-readable URIs (e.g. by not escaping ':' characters within
literal IPv6 addresses). As a side-effect, this allows relative URIs
containing parameter lists (e.g. "../boot.php##params") to function
as expected.
Add validity check for FTP paths to ensure that only printable
characters are accepted (since FTP is a human-readable line-based
protocol with no support for character escaping).
Construct TFTP next-server+filename URIs directly, rather than parsing
a constructed "tftp://..." string,
Add self-tests for URI functions.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Fix incorrect calculation used to determine length of data to be
copied within a literal data block, and add a test case to prevent
this bug from going undetected in future.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Explicitly separate the concept of a completed fetched setting
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>
[settings] Change "not-found" semantics of fetch_setting_copy()
fetch_settings_copy() currently returns success and a NULL data
pointer to indicate a non-existent setting. This is intended to allow
the caller to differentiate between a non-existent setting and an
error in allocating memory for the copy of the setting.
The underlying settings blocks' fetch() methods provide no way to
perform an existence check separate from an attempt to fetch the
setting. A "non-existent setting" therefore means simply a setting
for which an error was encountered when attempting to fetch from every
settings block within the subtree.
Since any underlying error within a settings block (e.g. a GuestRPC
failure when attempting to retrieve a VMware GuestInfo setting) will
produce the effect of a "non-existent setting", it seems somewhat
meaningless to give special treatment to memory allocation errors
within fetch_setting_copy().
Remove the special treatment and simplify the semantics of
fetch_setting_copy() by directly passing through any underlying error
(including non-existence) encountered while fetching the setting.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
RFC2560 mandates that a valid OCSP response will contain exactly one
relevant certificate. However, some OCSP responders include
extraneous certificates. iPXE currently assumes that the first
certificate in the OCSP response is the relevant certificate; OCSP
checks will therefore fail if the responder includes the extraneous
certificates before the relevant certificate.
Fix by using the responder ID to identify the relevant certificate.
Reported-by: Christian Stroehmeier <stroemi@mail.uni-paderborn.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Report meaningful error when certificate chain validation fails
If a certificate chain contains no certificate which can be validated
as a standalone certificate (i.e. contains no trusted root
certificates or previously-validated certificates) then iPXE will
currently return a fixed error EACCES_UNTRUSTED. This masks the
actual errors obtained when attempting to validate each certificate as
a standalone certificate, and so makes troubleshooting difficult for
the end user.
Fix by instead returning the error obtained when attempting to
validate the final certificate in the chain as a standalone
certificate. This error is most likely (though not guaranteed) to
represent the "real" problem.
Reported-by: Sven Dreyer <sven@dreyer-net.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Discarding the active ARP cache entry in the middle of a download will
substantially disrupt the TCP stream. Try to minimise any such
disruption by treating ARP cache entries as expensive, and discarding
them only when nothing else is available to discard.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Allow an error margin on X.509 certificate validity periods
iPXE has no concept of the local time zone, mainly because there is no
viable way to obtain time zone information in the absence of local
state. This causes potential problems with newly-issued certificates
and certificates that are about to expire.
Avoid such problems by allowing an error margin of around 12 hours on
certificate validity periods, similar to the error margin already
allowed for OCSP response timestamps.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Rename KEY= to PRIVKEY= and "key" to "privkey"
The setting name "key" conflicts with the setting name "key" already
in use by the 802.11 code. Resolve the conflict by renaming the newer
setting to "privkey".
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add support for constructing OCSP queries and parsing OCSP responses.
(There is no support yet for actually issuing an OCSP query via an
HTTP POST.)
Signed-off-by: Michael Brown <mcb30@ipxe.org>
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>
CMS includes an unordered certificate set, from which certificates
must be extracted in order by matching up issuers with subjects. We
will use the same functionality as part of the automatic download of
cross-signing certificates. Generalise cms_find_subject() to
x509_find_subject(), and create x509_auto_append().
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Allow certificate chains to be long-lived data structures
At present, certificate chain validation is treated as an
instantaneous process that can be carried out using only data that is
already in memory. This model does not allow for validation to
include non-instantaneous steps, such as downloading a cross-signing
certificate, or determining certificate revocation status via OCSP.
Redesign the internal representation of certificate chains to allow
chains to outlive the scope of the original source of certificates
(such as a TLS Certificate record).
Allow for certificates to be cached, so that each certificate needs to
be validated only once.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Do not allow build-time cryptography settings to be overridden
If a root certificate has been explicitly specified at build time
using TRUST=/path/to/cert then do not allow this to be overridden even
from a trustworthy settings source (such as VMware GuestInfo).
Similarly, if a client certificate (and private key) has been
explicitly specified at build time, then do not allow it to be
overridden at runtime.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Allow trusted root certificate to be changed without a rebuild
Changing the trusted root certificate currently requires a rebuild of
the iPXE binary, which may be inconvenient or impractical.
Allow the list of trusted root certificate fingerprints to be
overridden using the "trust" setting, but only at the point of iPXE
initialisation. This prevents untrusted sources of settings
(e.g. DHCP) from subverting the chain of trust, while allowing
trustworthy sources to change the trusted root certificate without
requiring a rebuild.
The basic idea is that if you are able to manipulate a trustworthy
source of settings (e.g. VMware GuestInfo or non-volatile stored
options), then you would be able to replace the iPXE binary anyway,
and so no security is lost by allowing such sources to override the
list of trusted root certificates.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown