Am 20.06.2018 um 10:43 schrieb Andreas Steffen: > Hi Sven, > > you can use certificate policies which are based on OIDs. > > With swanctl.conf: > > remote { > auth = pubkey > cert_policy = <OID list> > ... > } > > or with ipsec.conf: > > rightcertpolicy=<OID list>
Thanks for pointing me to the right direction. I missed this in the manual page. So the manual page states: left|rightcertpolicy = <OIDs> Comma separated list of certificate policy OIDs the peer's certificate must have. OIDs are specified using the numerical dotted representation. Not supported for IKEv1 connections prior to 5.0.0. If I use the following configuration: conn rw-config also = rw-base ike = aes256-sha2_256-prfsha256-modp1024-modp2048,aes256gcm16-prfsha384-modp3072! esp = aes256-sha2_256-prfsha256,aes256-sha1,aes256gcm16-modp3072! leftsubnet = 10.0.0.0/8 # Split tunnel config leftid = "vpn.mydomain.net" # Must match remote part on the client side leftcert = server.crt # The server certificate to use leftsendcert = always # not "never" left = 10.0.1.99 rightdns = 10.0.0.10, 10.0.0.11 rightsourceip = %static, %dynamic rightcertpolicy = 1.3.6.1.5.5.7.3.2 conn ikev2-pubkey also = rw-config keyexchange = ikev2 auto = add I cannot connect and I get the following output: 8235[CFG] ike config match: 1052 (10.0.1.99 89.28.111.222 IKEv2) 8235[CFG] candidate "ikev2-pubkey", match: 20/1/1052 (me/other/ike) 8235[CFG] selected peer config 'ikev2-pubkey' 8235[CFG] using certificate "CN=MYNAME" 8235[CFG] certificate "CN=MYNAME" key: 4096 bit RSA 8235[CFG] using trusted intermediate ca certificate "DC=local, DC=my-group, CN=MY-CA01" 8235[CFG] certificate "DC=local, DC=my-group, CN=MY-SUB-CA01" key: 4096 bit RSA 8235[CFG] using trusted ca certificate "CN=MY-ROOT-CA01" 8235[CFG] certificate "CN=MY-ROOT-CA01" key: 4096 bit RSA 8235[CFG] reached self-signed root ca with a path length of 1 8235[IKE] authentication of 'MYNAME@my-group.local' with RSA signature successful 8235[CFG] constraint requires cert policy 1.3.6.1.5.5.7.3.2 8235[CFG] selected peer config 'ikev2-pubkey' inacceptable: non-matching authentication done 8235[CFG] no alternative config found If I remove the "rightcertpolicy" line, I can connect without problems. Any ideas? > On 20.06.2018 09:49, Sven Anders wrote: >> Hi Andreas, >> >> Am 19.06.2018 um 18:47 schrieb Andreas Steffen: >>> Hi Sven, >>> >>> according to section 5.1.3.12. "ExtendedKeyUsage" of RFC 4945 >>> "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX" >>> the IPsec User EKU is deprecated: >>> >>> The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in >>> certificates for use with IKE. Note that there were three IPsec- >>> related object identifiers in EKU that were assigned in 1999. The >>> semantics of these values were never clearly defined. The use of >>> these three EKU values in IKE/IPsec is obsolete and explicitly >>> deprecated by this specification. CAs SHOULD NOT issue certificates >>> for use in IKE with them. (For historical reference only, those >>> values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp- >>> ipsecUser.) >>> >>> The only EKU flags our X.509 class supports are ocspSigning, ClientAuth, >>> and ServerAuth. >> >> yes I know, that "IPsec User" is deprecated (I expected this remark would >> come), but I used it as an example here. We want to use our own OIDs. >> >> Because the ExtendedKeyUsage is a just a list of OIDs and there are no >> restrictions I know of, we use this to differentiate between classes of >> certificates we issue. >> >> If this isn't supported, how can we use StrongSwan to distinguish between >> groups of certificates without using Sub-CAs? >> We cannot be the first with this requirement... >> >>> On 19.06.2018 18:22, Sven Anders wrote: >>>> >>>> We want to limit the usage of certificates by defining certain >>>> "Extended Key Usage" (EKU) flags to them. >>>> >>>> As an example, we want to set the "IPSec User" usage (1.3.6.1.5.5.7.3.7) >>>> and >>>> only allow connection via IPSec, if it is set. We may use some other flags >>>> out of our own space too. >>>> >>>> How can I check in StrongSwan, if a certain EKU exists? Regards Sven Anders -- Sven Anders <and...@anduras.de> () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin