[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>
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] 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>
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>
Alexander Chernyakhovsky