<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 12/17/2016 17:32, Karl Denninger
      wrote:<br>
    </div>
    <blockquote
      cite="mid:0eb3c506-2fd3-319f-c99d-f6ddec5bca3a@denninger.net"
      type="cite">
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      <p>EAP-CHAPv2 is working against Win10 with a reloaded machine.</p>
      <p>However, user certificate authentication is not.</p>
      <p>Strongswan 5.1.1 is built with:</p>
      <p> $ ./configure --enable-kernel-pfkey --enable-kernel-pfroute
        --disable-kernel-netlink --disable-tools --disable-scripts
        --with-group=wheel --enable-eap-gtc --enable-xauth-pam
        --enable-eap-mschapv2 --enable-md4 --enable-eap-identity
        --enable-curl --enable-eap-tls<br>
        <br>
      </p>
      <p>The config file fragment is:</p>
      <p>conn %default<br>
                keyingtries=3<br>
                keyexchange=ikev2<br>
        <br>
        conn WinUserCert<br>
                left=%any<br>
                leftsubnet=0.0.0.0/0<br>
                leftcert=genesis.denninger.net.crt<br>
                leftauth=pubkey<br>
                right=%any<br>
                rightsourceip=192.168.2.0/24<br>
                rightsendcert=never<br>
                rightauth=eap-tls<br>
                eap_identity=%identity<br>
                auto=add<br>
                dpdaction=clear<br>
                dpddelay=300s<br>
      </p>
      <p>The user certificate checks against the CA:</p>
      <p>openssl verify -CAfile CudaSystems.new.crt ksd.ocsp.crt<br>
        ksd.ocsp.crt: OK<br>
      </p>
      <p>The CA file is in cacerts (and is working to self-verify the
        machine certificate for the gateway, which is signed by the same
        CA)</p>
      <p>The user certificate is:</p>
      <p>Certificate:<br>
            Data:<br>
                Version: 3 (0x2)<br>
                Serial Number: 41 (0x29)<br>
            Signature Algorithm: sha256WithRSAEncryption<br>
                Issuer: C=US, ST=Florida, L=Niceville, O=Cuda Systems
        LLC, CN=Cuda Systems LLC CA/emailAddress=Cuda Systems LLC CA<br>
                Validity<br>
                    Not Before: Apr 21 02:21:59 2015 GMT<br>
                    Not After : Apr 19 02:21:59 2020 GMT<br>
                Subject: C=US, ST=Florida, O=Cuda Systems LLC, CN=Karl
        Denninger (OCSP)<br>
                Subject Public Key Info:<br>
                    Public Key Algorithm: rsaEncryption<br>
                        Public-Key: (4096 bit)<br>
                        Modulus:<br>
                           
        00:b9:84:58:f8:40:76:98:6b:59:de:0a:e5:54:ef:<br>
                           
        13:9a:71:2f:76:e5:45:03:f2:18:5d:c0:a6:35:23:<br>
                           
        82:d6:af:a9:4d:58:f2:96:c8:dc:1c:a0:5c:38:f6:<br>
                           
        fd:4c:fd:4a:2f:17:56:3f:e4:35:b2:84:8e:44:61:<br>
        ......</p>
      <p>                Exponent: 65537 (0x10001)<br>
                X509v3 extensions:<br>
                    Authority Information Access:<br>
                        OCSP - URI:<a moz-do-not-send="true"
          class="moz-txt-link-freetext"
          href="http://cudasystems.net:8888">http://cudasystems.net:8888</a><br>
        <br>
                    X509v3 Basic Constraints:<br>
                        CA:FALSE<br>
                    Netscape Cert Type:<br>
                        SSL Client, S/MIME<br>
                    X509v3 Key Usage:<br>
                        Digital Signature, Non Repudiation, Key
        Encipherment<br>
                    Netscape Comment:<br>
                        OpenSSL Generated Certificate<br>
                    X509v3 Subject Key Identifier:<br>
                       
        C5:1C:94:2D:E9:C9:68:5C:17:46:D4:FB:F5:A3:66:20:1F:EE:E5:59<br>
                    X509v3 Authority Key Identifier:<br>
                       
        keyid:24:71:9B:9D:85:7D:FC:DD:DD:BD:B0:CA:92:94:03:A1:FA:D3:6D:35<br>
        <br>
                    X509v3 Subject Alternative Name:<br>
                        <a moz-do-not-send="true"
          class="moz-txt-link-abbreviated"
          href="mailto:email:karl@denninger.net">email:karl@denninger.net</a><br>
            Signature Algorithm: sha256WithRSAEncryption<br>
                 4f:7f:77:18:b6:62:a8:c2:61:88:62:c9:ba:78:18:a7:26:ee:<br>
                 d0:55:6b:f1:8b:5b:ea:9c:1c:f7:28:4f:87:6a:9a:a8:21:94:<br>
                 bc:fc:fa:25:07:f8:70:89:8d:14:00:4d:51:b2:30:49:ef:21:<br>
                 23:8a:15:51:c2:e9:a6:48:1b:e4:a0:ec:9f:1b:7d:2e:3e:7e:<br>
                 32:83:8b:db:26:44:7d:95:3c:fc:77:6d:5f:3e:c8:56:11:36:<br>
        .....<br>
      </p>
      <br>
      But StrongSwan rejects verification with:<br>
      <br>
      Dec 17 16:53:55 NewFS charon: 14[NET] received packet: from
      192.168.1.19[500] to 70.169.168.7[500] (880 bytes)<br>
      Dec 17 16:53:55 NewFS charon: 14[ENC] parsed IKE_SA_INIT request 0
      [ SA KE No N(NATD_S_IP) N(NATD_D_IP) V V V V ]<br>
      Dec 17 16:53:55 NewFS charon: 14[IKE] received MS NT5 ISAKMPOAKLEY
      v9 vendor ID<br>
      Dec 17 16:53:55 NewFS charon: 14[IKE] received MS-Negotiation
      Discovery Capable vendor ID<br>
      Dec 17 16:53:55 NewFS charon: 14[IKE] received Vid-Initial-Contact
      vendor ID<br>
      Dec 17 16:53:55 NewFS charon: 14[ENC] received unknown vendor ID:
      01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02<br>
      Dec 17 16:53:55 NewFS charon: 14[IKE] 192.168.1.19 is initiating
      an IKE_SA<br>
      Dec 17 16:53:55 NewFS charon: 14[ENC] generating IKE_SA_INIT
      response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ]<br>
      Dec 17 16:53:55 NewFS charon: 14[NET] sending packet: from
      70.169.168.7[500] to 192.168.1.19[500] (308 bytes)<br>
      Dec 17 16:53:55 NewFS charon: 12[NET] received packet: from
      192.168.1.19[4500] to 70.169.168.7[4500] (1628 bytes)<br>
      Dec 17 16:53:55 NewFS charon: 12[ENC] parsed IKE_AUTH request 1 [
      IDi CERTREQ N(MOBIKE_SUP) CPRQ(ADDR DNS NBNS SRV ADDR6 DNS6 SRV6)
      SA TSi TSr ]<br>
      Dec 17 16:53:55 NewFS charon: 12[IKE] received cert request for
      "C=US, ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda
      Systems LLC CA, E=Cuda Systems LLC CA"<br>
      Dec 17 16:53:55 NewFS charon: 12[IKE] received 57 cert requests
      for an unknown ca<br>
      Dec 17 16:53:55 NewFS charon: 12[CFG] looking for peer configs
      matching 70.169.168.7[%any]...192.168.1.19[192.168.1.19]<br>
      Dec 17 16:53:55 NewFS charon: 12[CFG] selected peer config
      'WinUserCert'<br>
      Dec 17 16:53:55 NewFS charon: 12[IKE] initiating EAP_IDENTITY
      method (id 0x00)<br>
      Dec 17 16:53:55 NewFS charon: 12[IKE] peer supports MOBIKE<br>
      Dec 17 16:53:56 NewFS charon: 12[IKE] authentication of 'C=US,
      ST=Florida, O=Cuda Systems LLC, CN=genesis.denninger.net, <a
        moz-do-not-send="true" class="moz-txt-link-abbreviated"
        href="mailto:E=postmaster@denninger.net">E=postmaster@denninger.net</a>'
      (myself) with RSA signature successful<br>
      Dec 17 16:53:56 NewFS charon: 12[IKE] sending end entity cert
      "C=US, ST=Florida, O=Cuda Systems LLC, CN=genesis.denninger.net, <a
        moz-do-not-send="true" class="moz-txt-link-abbreviated"
        href="mailto:E=postmaster@denninger.net">E=postmaster@denninger.net</a>"<br>
      Dec 17 16:53:56 NewFS charon: 12[ENC] generating IKE_AUTH response
      1 [ IDr CERTAUTH EAP/REQ/ID ]<br>
      Dec 17 16:53:56 NewFS charon: 12[NET] sending packet: from
      70.169.168.7[4500] to 192.168.1.19[4500] (2420 bytes)<br>
      Dec 17 16:53:56 NewFS charon: 16[NET] received packet: from
      192.168.1.19[4500] to 70.169.168.7[4500] (84 bytes)<br>
      Dec 17 16:53:56 NewFS charon: 16[ENC] parsed IKE_AUTH request 2 [
      EAP/RES/ID ]<br>
      <br>
      Looks ok up to here -- the gateway authenticated itself against
      the CA and sent down the gateway certificate.<br>
      <br>
      Dec 17 16:53:56 NewFS charon: 16[IKE] received EAP identity 'Karl
      Denninger (OCSP)'<br>
      <br>
      (Uh, why didn't I get the SAN back?  It IS set; the CN is
      worthless on a S/MIME & VPN cert allegedly....  I can't set it
      anyway, and )<br>
      <br>
      Dec 17 16:53:56 NewFS charon: 16[IKE] initiating EAP_TLS method
      (id 0x44)<br>
      Dec 17 16:53:56 NewFS charon: 16[ENC] generating IKE_AUTH response
      2 [ EAP/REQ/TLS ]<br>
      Dec 17 16:53:56 NewFS charon: 16[NET] sending packet: from
      70.169.168.7[4500] to 192.168.1.19[4500] (68 bytes)<br>
      Dec 17 16:53:56 NewFS charon: 16[NET] received packet: from
      192.168.1.19[4500] to 70.169.168.7[4500] (244 bytes)<br>
      Dec 17 16:53:56 NewFS charon: 16[ENC] parsed IKE_AUTH request 3 [
      EAP/RES/TLS ]<br>
      Dec 17 16:53:56 NewFS charon: 16[TLS] negotiated TLS 1.2 using
      suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA<br>
      Dec 17 16:53:56 NewFS charon: 16[TLS] sending TLS server
      certificate 'C=US, ST=Florida, O=Cuda Systems LLC,
      CN=genesis.denninger.net, <a moz-do-not-send="true"
        class="moz-txt-link-abbreviated"
        href="mailto:E=postmaster@denninger.net">E=postmaster@denninger.net</a>'<br>
      Dec 17 16:53:56 NewFS charon: 16[TLS] sending TLS cert request for
      'C=US, ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda
      Systems LLC CA, E=Cuda Systems LLC CA'<br>
      Dec 17 16:53:56 NewFS charon: 16[ENC] generating IKE_AUTH response
      3 [ EAP/REQ/TLS ]<br>
      Dec 17 16:53:56 NewFS charon: 16[NET] sending packet: from
      70.169.168.7[4500] to 192.168.1.19[4500] (1084 bytes)<br>
      Dec 17 16:53:56 NewFS charon: 16[NET] received packet: from
      192.168.1.19[4500] to 70.169.168.7[4500] (68 bytes)<br>
      Dec 17 16:53:56 NewFS charon: 16[ENC] parsed IKE_AUTH request 4 [
      EAP/RES/TLS ]<br>
      Dec 17 16:53:56 NewFS charon: 16[ENC] generating IKE_AUTH response
      4 [ EAP/REQ/TLS ]<br>
      Dec 17 16:53:56 NewFS charon: 16[NET] sending packet: from
      70.169.168.7[4500] to 192.168.1.19[4500] (1084 bytes)<br>
      Dec 17 16:53:56 NewFS charon: 05[NET] received packet: from
      192.168.1.19[4500] to 70.169.168.7[4500] (68 bytes)<br>
      Dec 17 16:53:56 NewFS charon: 05[ENC] parsed IKE_AUTH request 5 [
      EAP/RES/TLS ]<br>
      Dec 17 16:53:56 NewFS charon: 05[ENC] generating IKE_AUTH response
      5 [ EAP/REQ/TLS ]<br>
      Dec 17 16:53:56 NewFS charon: 05[NET] sending packet: from
      70.169.168.7[4500] to 192.168.1.19[4500] (1012 bytes)<br>
      Dec 17 16:54:11 NewFS charon: 11[NET] received packet: from
      192.168.1.19[4500] to 70.169.168.7[4500] (1460 bytes)<br>
      Dec 17 16:54:11 NewFS charon: 11[ENC] parsed IKE_AUTH request 6 [
      EAP/RES/TLS ]<br>
      Dec 17 16:54:11 NewFS charon: 11[ENC] generating IKE_AUTH response
      6 [ EAP/REQ/TLS ]<br>
      Dec 17 16:54:11 NewFS charon: 11[NET] sending packet: from
      70.169.168.7[4500] to<br>
       192.168.1.19[4500] (68 bytes)<br>
      Dec 17 16:54:11 NewFS charon: 11[NET] received packet: from
      192.168.1.19[4500] to 70.169.168.7[4500] (1180 bytes)<br>
      Dec 17 16:54:11 NewFS charon: 11[ENC] parsed IKE_AUTH request 7 [
      EAP/RES/TLS ]<br>
      Dec 17 16:54:11 NewFS charon: 11[TLS] received TLS peer
      certificate 'C=US, ST=Florida, O=Cuda Systems LLC, CN=Karl
      Denninger (OCSP)'<br>
      Dec 17 16:54:11 NewFS charon: 11[TLS] no trusted certificate found
      for 'Karl Denninger (OCSP)' to verify TLS peer<br>
      <br>
      What is it looking for here and not finding?  If an entry in
      ipsec.secrets, what's the syntax (the obvious doesn't work)<br>
      <br>
      Dec 17 16:54:11 NewFS charon: 11[TLS] sending fatal TLS alert
      'certificate unknown'<br>
      Dec 17 16:54:11 NewFS charon: 11[ENC] generating IKE_AUTH response
      7 [ EAP/REQ/TLS ]<br>
      Dec 17 16:54:11 NewFS charon: 11[NET] sending packet: from
      70.169.168.7[4500] to 192.168.1.19[4500] (76 bytes)<br>
      Dec 17 16:54:11 NewFS charon: 13[NET] received packet: from
      192.168.1.19[4500] to 70.169.168.7[4500] (68 bytes)<br>
      Dec 17 16:54:11 NewFS charon: 13[ENC] parsed IKE_AUTH request 8 [
      EAP/RES/TLS ]<br>
      Dec 17 16:54:11 NewFS charon: 13[IKE] EAP method EAP_TLS failed
      for peer 192.168.1.19<br>
      Dec 17 16:54:11 NewFS charon: 13[ENC] generating IKE_AUTH response
      8 [ EAP/FAIL]<br>
      <br>
      Incidentally this same cert works on Android against the same
      server using the StrongSwan client...<br>
      <br>
      I'm obviously missing something.... thanks in advance!<br>
      <br>
      <div class="moz-signature">-- <br>
        Karl Denninger<br>
        <a moz-do-not-send="true" href="mailto:karl@denninger.net">karl@denninger.net</a><br>
        <i>The Market Ticker</i><br>
        <font size="-2"><i>[S/MIME encrypted email preferred]</i></font>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a>
<a class="moz-txt-link-freetext" href="https://lists.strongswan.org/mailman/listinfo/users">https://lists.strongswan.org/mailman/listinfo/users</a></pre>
    </blockquote>
    <br>
    If I set <a class="moz-txt-link-abbreviated" href="mailto:eip_identity=user@host.domain">eip_identity=user@host.domain</a> explicitly in the config file
    to my SAN then it finds the cert in the valid set and connects.<br>
    <br>
    But shouldn't Windows be sending that back?  Or do it do so only if
    CN is blank (if so, BARF -- shouldn't it PREFER the SAN if that's
    set over the CN?!)<br>
    <br>
    <div class="moz-signature">-- <br>
      Karl Denninger<br>
      <a href="mailto:karl@denninger.net">karl@denninger.net</a><br>
      <i>The Market Ticker</i><br>
      <font size="-2"><i>[S/MIME encrypted email preferred]</i></font>
    </div>
  </body>
</html>