[strongSwan] Certificate checks while using EAP-TLS
andreas.schantin at uni-siegen.de
Thu Oct 7 15:27:52 CEST 2010
I have a question concerning the validation of certificates when using
EAP-TLS (strongswan-4.5.0dr4). I've had a bit of trouble following the
example from the wiki while trying to set up an connection using EAP-TLS
as authentication. As it turned out this was due to the missing
subjectAlternativeName in the client's certificate. After issuing a
certificate with the client's IP as the subjectAlternativeName
everything worked like a charm.
Now here's my problem. I would like to let the clients authenticate
themselves with previously issued certificates that contains an email
address in the subjectAlternativeName (or that have no
subjectAlternativeName at all). But during my experiments StrongSWAN
always rejects these certificates as:
Oct 7 15:10:12 vpntest charon: 01[TLS] received TLS Certificate
handshake (1655 bytes)
Oct 7 15:10:12 vpntest charon: 01[TLS] received TLS peer certificate
'C=DE, ST=Nordrhein-Westfalen, L=Siegen, [...]'
Oct 7 15:10:12 vpntest charon: 01[TLS] received TLS ClientKeyExchange
handshake (66 bytes)
Oct 7 15:10:12 vpntest charon: 01[TLS] received TLS CertificateVerify
handshake (258 bytes)
Oct 7 15:10:12 vpntest charon: 01[TLS] no trusted certificate found for
'184.108.40.206' to verify TLS peer
Oct 7 15:10:12 vpntest charon: 01[TLS] processing TLS ChangeCipherSpec
record (1 bytes)
Oct 7 15:10:12 vpntest charon: 01[TLS] processing TLS Handshake record
Oct 7 15:10:12 vpntest charon: 01[TLS] sending fatal TLS alert
The same error like when I used certificates without subjectAlternativeName.
I guess this is because charon tries to match the subjectAlternativeName
to the client's IP or DNS name, right? But how can I influence that
behavior? I just want to check if that client's certificate is issued by
a certain CA (and maybe has a certain field in the DN). Is that even
possible or desirable? My client anyway won't have fixed IPs nor
resolvable hostnames that I can issue the certificates for anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6125 bytes
Desc: S/MIME Cryptographic Signature
More information about the Users