[strongSwan] FW: defining a connection profile using DNS name in the cert's alt subject name cert field
Noel Kuntze
noel.kuntze at thermi.consulting
Wed Jun 2 23:23:39 CEST 2021
Hello Dave,
Thank you for your persistence.
The error in your config is the following:
In your server config ikev2-conn-eNB-test-altname :
You implicitely configure the local identity here:
local-1 {
auth = pubkey
certs = gateway.crt
}
It defaults to the DN of gateway.crt
Then you explicitely define the required remote ID here:
remote-1 {
auth = pubkey
id = DNS:zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org
}
Up to now, that's all fine.
The formulated requirement is:
- both use pubkey auth
- local identity is the DN of gateway.crt
- remote identity has to be of type DNS and value zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org
- remote certificate has to be signed by any valid and loaded CA
Now the client config ikev2-pubkey:
remote_addrs = 2001:1890:111b:1c03::2 # tunnel addr for C1/D1
local {
auth = pubkey
certs = zakr3dsegw51.crt
}
remote {
auth = pubkey
}
- both use pubkey auth
- remote ID has to be 2001:1890:111b:1c03::2
- local ID is DN of zakr3dsegw51.
- remote certificate has to be signed by any valid and loaded CA
That's the `pki --print`output of zakr3dsegw51:
subject: "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW, CN=zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org"
issuer: "C=US, ST=Illinois, O=AT&T FSG Services, Inc., OU=Network Cloud and Infrastructure, CN=FSG CA Signing Certificate, E=df1672 at att.com"
validity: not before Mar 24 19:40:28 2021, ok
not after Mar 23 19:40:28 2026, ok (expires in 1754 days)
serial: a4:ad:fc:e0:19:40:b6:62:78:58:3b:7e:74:d4:2a:57
altNames: zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org
flags: serverAuth clientAuth
authkeyId: b9:19:aa:84:72:ff:c5:c8:a3:5e:05:46:ff:f5:15:3a:63:d4:9e:d0
subjkeyId: 36:ea:bd:ec:7f:da:4e:5c:33:6b:cd:dd:85:72:d4:f2:e8:d9:2f:51
pubkey: RSA 2048 bits
keyid: e6:4c:d3:b6:c7:e5:08:1d:f1:ad:77:04:d1:c5:4e:49:42:61:84:1e
subjkey: 36:ea:bd:ec:7f:da:4e:5c:33:6b:cd:dd:85:72:d4:f2:e8:d9:2f:51
Valid IDs:
- DNS type, value: zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org
- DN type, value: "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW, CN=zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org"
In the log we see the following:
[...]
Mon, 2021-05-10, 10:12:41 07[CFG] vici client 4 requests: load-conn
Mon, 2021-05-10, 10:12:41 07[CFG] conn ikev2-conn-eNB-test-altname:
Mon, 2021-05-10, 10:12:41 07[CFG] child ikev2-conn-eNB-test-altname:
[...]
Mon, 2021-05-10, 10:12:41 07[CFG] id not specified, defaulting to cert subject 'C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW, CN=zrdm55asegw52.epc.mnc670.mcc312.3gppnetwork.org'
[...]
Mon, 2021-05-10, 10:12:41 07[CFG] local:
Mon, 2021-05-10, 10:12:41 07[CFG] id = C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW, CN=zrdm55asegw52.epc.mnc670.mcc312.3gppnetwork.org
Mon, 2021-05-10, 10:12:41 07[CFG] class = public key
Mon, 2021-05-10, 10:12:41 07[CFG] remote:
Mon, 2021-05-10, 10:12:41 07[CFG] id = zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org
Mon, 2021-05-10, 10:12:41 07[CFG] class = public key
Mon, 2021-05-10, 10:12:41 07[CFG] updated vici connection: ikev2-conn-eNB-test-altname
[...]
That means your actually loaded config is this on the server side:
local-1 {
auth = pubkey
certs = gateway.crt
id = "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW, CN=zrdm55asegw52.epc.mnc670.mcc312.3gppnetwork.org"
}
remote-1 {
auth = pubkey
id = DNS:zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org
}
and on the client side it is this:
local {
auth = pubkey
certs = zakr3dsegw51.crt
id = "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW, CN=zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org"
}
remote {
auth = pubkey
id = 2001:1890:111b:1c03::2 (value not sent because of $reasons)
}
Fron the log:
[...]
Mon, 2021-05-10, 10:13:44 13[IKE] <1> received end entity cert "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW, CN=zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org"
Mon, 2021-05-10, 10:13:44 13[CFG] <1> looking for peer configs matching 2001:1890:111b:1c03::2[%any]...2001:1890:111b:1004::22[C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW, CN=zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org]
Mon, 2021-05-10, 10:13:44 13[CFG] <1> no matching peer config found
[...]
That peer configs matching line says the following:
I look for a config where the local allowed addresses (local_addrs) contain 2001:1890:111b:1c03::2 and the identity can be ANY identity (any type, any value)
(that is because in the IKE packet the other peer (client) sent, there is no IDr, just an IDi (IDr == Identity Responder, IDi == Identity Initiator), that is valid behaviour)
and the remote allowed addresses contain 2001:1890:111b:1004::22 and the allowed identities have to contain "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW, CN=zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org" (type[1] unknown, probably DN).
Looking at your currently loaded server side config, which is the following:
- local ID "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW, CN=zrdm55asegw52.epc.mnc670.mcc312.3gppnetwork.org"
- remote ID "zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org"
Explicitely compared as follows:
local ID %any contains "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW, CN=zrdm55asegw52.epc.mnc670.mcc312.3gppnetwork.org" (that's fine)
remote ID "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW, CN=zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org" DOES NOT MATCH zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org
Solutions:
a) Explicitely set the remote ID on the server side to "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW, CN=zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org" (that's the ID the client actually sends)
* See if the identity check later on the client side works out once the identity the server sends for itself is known to the client. If it doesn't, mutate configs accordingly.
b) Set the local ID on the client to "zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org" (that should/will work because the ID is exactly contained as type FQDN in the SAN of the client cert)
remote_addrs = 2001:1890:111b:1c03::2 # tunnel addr for C1/D1
local {
auth = pubkey
certs = zakr3dsegw51.crt
id = "zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org"
}
remote {
auth = pubkey
}
c) Remove the identity in the server config's remote auth section (will permit any certificate if sent id is part of the certificate, thus any correctly configured client with a trusted certificate)
I presume this is a POC where in the end a single CA or CAs under a common sub ca issue client certificates. In that case just get that cert and set it in remote.cacerts. strongSwan will ensure that certificates of clients that try to authenticate have to have the configured CA certificate in its trust path.
That's the preferred solution. That way you can use that single connection definition for all clients. The lookup for configs while config matching in the code is linear so keep your number of loaded connections at a reasonable number. Also, don't configure DNS names as local or remote addresses.
That will cause a DNS lookup for every config match (not good).
Let me know if this helps.
Kind regards
Noel
Addendum:
1) Standardized Identity types (from RFC5996)
ID Type Value
-------------------------------------------------------------------
ID_IPV4_ADDR 1
A single four (4) octet IPv4 address.
ID_FQDN 2
A fully-qualified domain name string. An example of an ID_FQDN
is "example.com". The string MUST NOT contain any terminators
(e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII;
for an "internationalized domain name", the syntax is as defined
in [IDNA <https://datatracker.ietf.org/doc/html/rfc5996#ref-IDNA>], for example "xn--tmonesimerkki-bfbb.example.net".
ID_RFC822_ADDR 3
A fully-qualifiedRFC 822 <https://datatracker.ietf.org/doc/html/rfc822> email address string. An example of a
ID_RFC822_ADDR is "jsmith at example.com". The string MUST NOT
contain any terminators. Because of [EAI <https://datatracker.ietf.org/doc/html/rfc5996#ref-EAI>], implementations would
be wise to treat this field as UTF-8 encoded text, not as
pure ASCII.
ID_IPV6_ADDR 5
A single sixteen (16) octet IPv6 address.
ID_DER_ASN1_DN 9
The binary Distinguished Encoding Rules (DER) encoding of an
ASN.1 X.500 Distinguished Name [PKIX <https://datatracker.ietf.org/doc/html/rfc5996#ref-PKIX>].
ID_DER_ASN1_GN 10
The binary DER encoding of an ASN.1 X.509 GeneralName [PKIX <https://datatracker.ietf.org/doc/html/rfc5996#ref-PKIX>].
ID_KEY_ID 11
An opaque octet stream that may be used to pass vendor-
specific information necessary to do certain proprietary
types of identification.
2) known strongSwan identity types (from man swanctl.conf):
The following prefixes are known: ipv4, ipv6, rfc822, email, userfqdn, fqdn, dns, asn1dn, asn1gn and keyid. Custom type prefixes may be specified by surrounding the numerical type value by curly brackets.
Am 02.06.21 um 21:06 schrieb FINLEY, DAVID BRIAN:
> Hello, I've resent this a couple of times over the last few weeks with no response. Appreciate that you may be too busy, just let me know if that's the case so that I know you received it and then I wont send any further follow ups.
> Thx.
>
> Dave Finley
> df1672 at att.com
> (630) 719-4391 (desk)
> (630) 740-5198 (mobile)
>
> -----Original Message-----
> From: FINLEY, DAVID BRIAN
> Sent: Monday, May 10, 2021 10:20 AM
> To: Noel Kuntze <noel.kuntze at thermi.consulting>
> Subject: RE: [strongSwan] defining a connection profile using DNS name in the cert's alt subject name cert field
>
> I set my charon-logging.conf file up to match whats on the Wiki page, although it seems like what I have now is less verbose than before. Anyway, the settings I used were:
>
> filelog {
> charon-systemd {
> path = /var/log/charon_debug.log
> time_format = %a, %Y-%m-%d, %H:%M:%S
> default = 2
> mgr = 0
> net = 1
> enc = 1
> asn = 1
> job = 1
> ike_name = yes
> append = no
> flush_line = yes
> }
> }
>
> Thanks.
>
> Dave Finley
> df1672 at att.com
> (630) 719-4391 (desk)
> (630) 740-5198 (mobile)
>
> -----Original Message-----
> From: Noel Kuntze <noel.kuntze at thermi.consulting>
> Sent: Saturday, May 08, 2021 3:09 AM
> To: FINLEY, DAVID BRIAN <df1672 at att.com>
> Subject: Re: [strongSwan] defining a connection profile using DNS name in the cert's alt subject name cert field
>
> Hi,
>
> The cert looks okay, the log contains nothing useful though.
> Please create logs using the settings on the HelpRequests[1] page on the wiki.
> Those will then contain useful information.
>
> Kind regards
> Noel
>
> [1] https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests
>
> Am 06.05.21 um 16:26 schrieb FINLEY, DAVID BRIAN:
>> Forgot that our mail server probably wouldn't allow that crt file through, renamed it as txt this time. Also attached the charon.log file from the connection failure with msg level turned up to 4. I search for "looking for" when I want to go right to the point in the log where the profile lookup is attempted and then fails.
>> thx
>>
>> Dave Finley
>> df1672 at att.com
>> (630) 719-4391 (desk)
>> (630) 740-5198 (mobile)
>>
>> -----Original Message-----
>> From: Noel Kuntze <noel.kuntze at thermi.consulting>
>> Sent: Wednesday, May 05, 2021 6:08 PM
>> To: FINLEY, DAVID BRIAN <df1672 at att.com>
>> Subject: Re: [strongSwan] defining a connection profile using DNS name in the cert's alt subject name cert field
>>
>> Hi,
>>
>> Your mailserver's security solution removed the certificate.
>> Config looks okay though.
>> The right syntax is described on the man page for swanctl.conf and you basically already tried it all.
>> Please get me the certificate and logs somehow.
>> Logs show you what happens for what reason.
>>
>> Kind regards
>> Noel
>>
>> Am 05.05.21 um 22:33 schrieb FINLEY, DAVID BRIAN:
>>> Noel,
>>> I attached the swanctl.conf file from both the client and the server. I
>> also attached the cert being used by the client so that you can see what the subject Alt name value is, if that's useful.
>>> thx
>>>
>>> Dave Finley
>>> df1672 at att.com
>>> (630) 719-4391 (desk)
>>> (630) 740-5198 (mobile)
>>>
>>> -----Original Message-----
>>> From: Noel Kuntze <noel.kuntze+strongswan-users-ml at thermi.consulting>
>>> Sent: Wednesday, May 05, 2021 2:00 PM
>>> To: FINLEY, DAVID BRIAN <df1672 at att.com>; Users at lists.strongswan.org
>>> Subject: Re: [strongSwan] defining a connection profile using DNS name
> in the cert's alt subject name cert field
>>> Hi,
>>>
>>> Please show your whole config and complete logs.
>>>
>>> Kind regards
>>> Noel
>>>
>>> Am 05.05.21 um 20:13 schrieb FINLEY, DAVID BRIAN:
>>>> *Hello,*
>>>>
>>>> **
>>>>
>>>> *I have ipsec clients using strongswan that are connecting to a strongswan server and want to setup connection profiles based on info in the subject Alt name string in each clients certificate. The subject Alt name in
>>> the client cert looks like this:*
>>>> **
>>>>
>>>> *X509v3 Subject Alternative Name:*
>>>>
>>>> * DNS:zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org*
>>>>
>>>> **
>>>>
>>>> *I've tried every variation I can think of using the "id = " parm in
>> swanctl.conf on the server and I cannot seem to get the strongswan server
>> to recognize/match on the subject Alt name in the clients cert. I've tried values including:*
>>>> **
>>>>
>>>> *id = DNS: zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org*
>>>>
>>>> *id = zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org*
>>>>
>>>> *id = FQDN: zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org*
>>>>
>>>> *id = @ zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org*
>>>>
>>>> *and others.*
>>>>
>>>> **
>>>>
>>>> *Any suggestions?*
>>>>
>>>> *Thx in advance. *
>>>>
>>>> **
>>>>
>>>> Dave Finley
>>>>
>>>> df1672 at att.com <mailto:df1672 at att.com>
>>>>
>>>> (630) 719-4391 (desk)**
>>>>
>>>> (630) 740-5198 (mobile)
>>>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20210602/3f146e91/attachment.sig>
More information about the Users
mailing list