From https://www.ietf.org/rfc/rfc5280.txt
> As noted in Section 4.1.2.2, serial numbers can be expected to
> contain long integers. Certificate users MUST be able to handle
> serialNumber values up to 20 octets in length. Conforming CAs MUST
> NOT use serialNumber values longer than 20 octets.
Without this, nghttpx will fatal.
jbraeg$ openssl x509 -in ~/test_certs/client.crt -serial -noout
serial=E0CFDFC7CEA10DF8AAF715C37FAEB410
jbraeg$ curl -k --key ~/test_certs/client.key --cert ~/test_certs/client.crt https://192.168.98.100:3000/; echo
curl: (56) Unexpected EOF
...
Assertion failed: n == b.size() (shrpx_tls.cc: get_x509_serial: 2051)
2019-01-03T20:25:21.289Z 1 1 f84316ae NOTICE (shrpx_log.cc:895) Worker process: [9] exited abnormally with status 0x06; exit status 0; signal Aborted(6)
2019-01-03T20:25:21.290Z 1 1 f84316ae NOTICE (shrpx.cc:4311) Shutdown momentarily
NPN has been superseeded by ALPN. OpenSSL provides a configure
option to disable npn (no-npn) which results in an OpenSSL
installation that defines OPENSSL_NO_NEXTPROTONEG in opensslconf.h
The #ifdef's look safe here (as the next_proto is initialized as
nullptr). Alteratively, macros could be defined for the used npn
methods that return a 0 for next_proto.
Signed-off-by: Bernard Spil <brnrd@FreeBSD.org>
BoringSSL has no "openssl/ocsp.h" nor most OCSP related APIs used in
shrpx_tls.cc. This commit add ifdefs to disable related code to allow
building nghttp2 with BoringSSL (again).
It's possible to use !defined(OPENSSL_IS_BORINGSSL), but since BoringSSL
defines OPENSSL_NO_OCSP which is more specific, I chose to go with the
latter one.
At least we should make sure that the OCSP response is targeted to the
expected certificate. This is important because we pass the file path
to the external script, and if the file is replaced because of
renewal, and nghttpx has not reloaded its configuration, the
certificate nghttpx has loaded and the one included in the file
differ. Verifying the OCSP response detects this, and avoids to send
wrong OCSP response.