Re: [strongSwan] Checking X509 Extended Key Usage
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 =
> ...
> }
>
> or with ipsec.conf:
>
> rightcertpolicy=
Thanks for pointing me to the right direction. I missed this in the
manual page.
So the manual page states:
left|rightcertpolicy =
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 () 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
Re: [strongSwan] Checking X509 Extended Key Usage
Hi Sven,
you can use certificate policies which are based on OIDs.
With swanctl.conf:
remote {
auth = pubkey
cert_policy =
...
}
or with ipsec.conf:
rightcertpolicy=
Best regards
Andreas
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]==
Re: [strongSwan] Checking X509 Extended Key Usage
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 () 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
