[strongSwan] Windows 10 authenticating with certificate fails

Yudi V yudi.tux at gmail.com
Tue Jan 24 11:12:53 CET 2017


On Wed, Jan 18, 2017 at 1:12 AM, Karl Denninger <karl at denninger.net> wrote:

>
> On 1/17/2017 07:10, Yudi V wrote:
>
> Hi,
>
> Error 13806
> Authentication from Windows 10 client fails when trying to use just
> certificates but EAP-Mschapv2 it works fine.
> Error 13806, "IKE failed to find valid machine certificate"
>
> I followed the advise about certificate needs for windows.
> All the keys are of type ecdsa:
>
> server cert:
> Ipsec   pki --pub --in  serverKey.der --type ecdsa |  ipsec pki --issue
> --cacert caCert.der --cakey caKey.der --dn "O=xxx, CN=home1234.ddns.com"
> --san="home1234.ddns.com"  --flag serverAuth --flag   ikeIntermediate   >
> serverCert.der
>
> client cert:
> ipsec pki --pub --in clientKey.der   --type ecdsa | ipsec pki --issue
> --cacert caCert.der --cakey caKey.der --dn "O=xxx, CN=client"  >
> clientCert.der
>
> converted der files to pem and packaged them into pkcs12 file
>
> openssl pkcs12 -export -in clientCert.pem -name "client" -inkey
> clientKey.pem -certfile caCert.pem -caname "xxx CA" -out clientCert.p12
>
> the first time I imported caCert.pem and clientCert.p12 files into windwos
> cert store I made a mistake and imported them into the current user account.
> Deleted them and imported them into the "computer account".
> and checked that it looks as in the last two sreencaps at
> https://wiki.strongswan.org/projects/strongswan/wiki/Win7Certs
> it says you have a private key that corresponds to this certificate.
>
> the san and CN are same for the server.
>
> ipsec.conf settings are:
>
> # ipsec.conf - strongSwan IPsec configuration file
>
> # basic configuration
>
> config setup
>         # strictcrlpolicy=yes
>         # uniqueids = no
>
> conn %default
>         keyexchange=ikev2
>         dpdaction=clear
>         dpddelay=300s
>
> # Add connections here.
>
>
> conn rw_pw                                       # this works
>         left=%any
>         leftsubnet=0.0.0.0/0,::0
>         leftauth=pubkey
>         leftcert=serverCert.der
>         leftid=home1234.ddns.com
>         leftfirewall=yes
>         lefthostaccess=yes
>         right=%any
>         rightauth=eap-mschapv2
>         rightsourceip=%dhcp
>         rightdns=192.168.3.1
>         eap_identity=%any
>         auto=add
>
> conn rw_cert                               # this fails
>         left=%any
>         leftsubnet=0.0.0.0/0,::0
>         leftauth=pubkey
>         leftcert=serverCert.der
>         leftid=home1234.ddns.com
>         leftfirewall=yes
>         lefthostaccess=yes
>         right=%any
>         rightauth=pubkey
>         rightcert=clientCert.pem
>         rightsourceip=%dhcp
>         rightdns=192.168.3.1
>         auto=add
>
>
> Any suggestion on how to fix this issue?
>
> regards
> Yudi
>
>
>
> Windows 10 is hosed in the head (as are other windows versions); here's
> what I have, and it works -- but it took a while to figure it out by
> turning debugging up and chasing what the two sides were saying to each
> other.  You do not want eap-mschapv2 unless you're using a password; for a
> machine certificate you want eap-tls (which may not be in your build; if
> not you will have to add it), and the eap_identity clause is also required.
>
> Snip from ipsec.conf:
>
> conn WinUserCert
>         left=%any
>         leftsubnet=0.0.0.0/0
>         leftcert=genesis.denninger.net.crt
>         leftauth=pubkey
>         right=%any
>         rightsourceip=192.168.2.0/24
>         rightauth=eap-tls
>         eap_identity=%identity
>         auto=add
>         dpdaction=clear
>         dpddelay=300s
>
> And then the cert must contain:
>
> Certificate:
>     Data:
>         Version: 3 (0x2)
>         Serial Number: 61 (0x3d)
>     Signature Algorithm: sha256WithRSAEncryption
>         Issuer: C=US, ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda
> Syste
> ms LLC CA/emailAddress=Cuda Systems LLC CA
>         Validity
>             Not Before: Dec 18 19:45:35 2016 GMT
>             Not After : Dec 17 19:45:35 2021 GMT
>         Subject: C=US, ST=Florida, O=Cuda Systems LLC,
> CN=karl at denninger.net
>         Subject Public Key Info:
>             Public Key Algorithm: rsaEncryption
>                 Public-Key: (4096 bit)
>                 Modulus:
>                     00:cd:8d:e6:66:b1:b3:b3:64:a1:8f:60:e4:d3:31:
>                     15:69:65:d1:36:22:3b:b8:17:ac:66:53:a3:7a:b6:
> .....
>
>                 Exponent: 65537 (0x10001)
>         X509v3 extensions:
>             Authority Information Access:
>                 OCSP - URI:http://cudasystems.net:8888
>
>             X509v3 Basic Constraints:
>                 CA:FALSE
>             Netscape Cert Type:
>                 SSL Client, S/MIME
>             X509v3 Key Usage:
>                 Digital Signature, Non Repudiation, Key Encipherment
>             Netscape Comment:
>                 OpenSSL Generated Certificate
>             X509v3 Subject Key Identifier:
>                 A5:F0:08:DF:2F:BB:E7:5A:69:F4:
> 0D:30:EA:F2:47:C7:C4:68:47:F3
>             X509v3 Authority Key Identifier:
>                 keyid:24:71:9B:9D:85:7D:FC:DD:
> DD:BD:B0:CA:92:94:03:A1:FA:D3:6D:35
>
>             X509v3 Subject Alternative Name:
>                 email:karl at denninger.net
>     Signature Algorithm: sha256WithRSAEncryption
>          62:07:a3:25:ba:0c:58:25:d7:1c:0f:c6:e8:67:fb:bc:77:c5:
> ....
>
> Note that BOTH SAN and CN are set in the user certificate.  SAN is there
> because I use this cert/key pair for S/MIME as well.  However, if you don't
> set CN to the same thing (which is usually not done if SAN is set) then
> Win10 will send the CN, whatever it may be (e.g. the user's full name), and
> StrongSwan won't find the cert because when it looks for it in the
> certificate store it compares against SAN and the comparison fails.
>
>
> --
> Karl Denninger
> karl at denninger.net
> *The Market Ticker*
> *[S/MIME encrypted email preferred]*
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
>


Hi Karl,

Sorry about the delayed reply.
I was finally able to use EAP-TLS, I think not having SAN same as CN on the
client certificate caused it to fail. I cannot be 100% sure as I also had
incorrect config to start with.


I just got one more issue to sort out. How does the server decide which
"conn" to use when a peer is trying to connect.
when I try to connect from the windows client, I can connect to either
rw_cert or rw_pw when one of them is commented out.  But if both of them
are listed, then it always tries to use rw_pw (ie, eap-mschapv2) if it is
listed before rw_cert.
If I swap the order of rw_pw and rw_cert (listed before rw_pw) then it
always tries to use eap-tls.

I am guessing the information sent by the client to the server has some
bearing on which "conn" to use.
Is there anyway to dictate which "conn" should be used?

My current config looks like below:

conn %default
        keyexchange=ikev2
        dpdaction=clear
        dpddelay=300s

        left=%any
        leftsubnet=0.0.0.0/0,::0
        leftauth=pubkey
        leftcert=serverCert.der
        leftid=home1234.ddns.com
        leftfirewall=yes
        lefthostaccess=yes

        right=%any
        rightsourceip=%dhcp
        rightdns=192.168.3.1

conn rw_pw
        rightauth=eap-mschapv2         #using password
        eap_identity=%any
        auto=add

conn rw_cert
        rightauth=eap-tls              #using certificate
        rightsendcert=never
        eap_identity=%any
        auto=add

thanks!
yudi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170124/644d31be/attachment-0001.html>


More information about the Users mailing list