Hi Sven, the certificate policy must be contained in all certificates of the X.509 trust chain. See the following example scenario:
https://www.strongswan.org/testing/testresults5dr/swanctl/rw-ed25519-certpol/ Regards Andreas On 20.06.2018 13:41, Sven Anders wrote: > 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 > -- ====================================================================== Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Networked Solutions HSR University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[INS-HSR]==
