On 3/17/21 11:02 AM, Stuart Henderson wrote:
On 2021/03/17 10:53, Jan Klemkow wrote:ping On Tue, Mar 09, 2021 at 03:49:32PM +0100, Jan Klemkow wrote:Hi, The verification of the https://ugos.ugm.ac.id certificate contains 2032 subject alt names which leads to the following error in LibreSSL. # openssl s_client -connect ugos.ugm.ac.id:443 ... verify error:num=17:out of memory ... The following diff sets the maximum number of SANs to the next higher number to fix this issue. OK? bye, Jan Index: lib/libcrypto/x509/x509_internal.h =================================================================== RCS file: /cvs/src/lib/libcrypto/x509/x509_internal.h,v retrieving revision 1.6 diff -u -p -r1.6 x509_internal.h --- lib/libcrypto/x509/x509_internal.h 5 Jan 2021 16:45:59 -0000 1.6 +++ lib/libcrypto/x509/x509_internal.h 9 Mar 2021 14:38:35 -0000 @@ -31,7 +31,7 @@ * Limit the number of names and constraints we will check in a chain * to avoid a hostile input DOS */ -#define X509_VERIFY_MAX_CHAIN_NAMES 512 +#define X509_VERIFY_MAX_CHAIN_NAMES 4096 #define X509_VERIFY_MAX_CHAIN_CONSTRAINTS 512/*I'm not really convinced we should do anything to accommodate this certificate which is beyond the limits of what CAs say they will issue.. We already reject a lot of certificates which are "more legit" than this due to the generalizedtimeformat checking so it's not like LibreSSL will accept everything permitted by OpenSSL..
Besides that, why 4096? Why not 8192 or 65536? RFC don't state any limit in the numbers of SANs, so you will always be able to create one which has more SANs than the limit libressl will impose.
smime.p7s
Description: S/MIME Cryptographic Signature
