diff options
author | Martin Willi <martin@strongswan.org> | 2017-02-21 16:54:57 +0100 |
---|---|---|
committer | Martin Willi <martin@strongswan.org> | 2017-02-27 09:36:48 +0100 |
commit | a115f4842880f1cf85de36e7d23652f9ddc93b73 (patch) | |
tree | 0777e8f26374b667653fb7acf1b58cd253e6cd36 /src/libstrongswan | |
parent | 6734d7a51aaf55002d97894a9ad0bd0a942769f5 (diff) | |
download | strongswan-a115f4842880f1cf85de36e7d23652f9ddc93b73.tar.bz2 strongswan-a115f4842880f1cf85de36e7d23652f9ddc93b73.tar.xz |
x509: Do not mark generated addrblock extension as critical
While RFC 3779 says we SHOULD mark it is critical, this has severe side effects
in practice. The addrblock extension is not widely used nor implemented, and
only a few applications can handle this extension. By marking it critical,
none of these applications can make use of such certificates where included
addrblocks do not matter, such as TLS/HTTPS.
If an application wants to make use of addrblocks, that is usually an explicit
decision. Then the very same application obviously can handle addrblocks, and
there is no need for the extension to be critical. In other words, for local
policy checks it is a local matter to handle the extension, hence making it
critical is usually not of much help.
Diffstat (limited to 'src/libstrongswan')
-rw-r--r-- | src/libstrongswan/plugins/x509/x509_cert.c | 3 |
1 files changed, 1 insertions, 2 deletions
diff --git a/src/libstrongswan/plugins/x509/x509_cert.c b/src/libstrongswan/plugins/x509/x509_cert.c index 2c03e972d..b77c5db4d 100644 --- a/src/libstrongswan/plugins/x509/x509_cert.c +++ b/src/libstrongswan/plugins/x509/x509_cert.c @@ -2289,9 +2289,8 @@ static bool generate(private_x509_cert_t *cert, certificate_t *sign_cert, chunk_from_chars(0x00,0x02)), asn1_wrap(ASN1_SEQUENCE, "m", v6blocks)); } - ipAddrBlocks = asn1_wrap(ASN1_SEQUENCE, "mmm", + ipAddrBlocks = asn1_wrap(ASN1_SEQUENCE, "mm", asn1_build_known_oid(OID_IP_ADDR_BLOCKS), - asn1_wrap(ASN1_BOOLEAN, "c", chunk_from_chars(0xFF)), asn1_wrap(ASN1_OCTET_STRING, "m", asn1_wrap(ASN1_SEQUENCE, "mm", v4blocks, v6blocks))); |