Project

General

Profile

Issue #2812

Unclear where to put Let's encrypt Root CA for strongSwan to work

Added by Alexander B about 1 month ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
configuration
Affected version:
5.7.1
Resolution:
No change required

Description

Hi. I have been unsuccessfully trying to connect my router to a remote server running strongSwan.

The error I am getting is:

12[CFG] no issuer certificate found for "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3"

The ipsec listcacerts returns nothing, but ipsec listcerts gives me the correct certificate for a remote host:

List of X.509 End Entity Certificates

  subject:  "CN=v.bougakov.com" 
  issuer:   "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" 
  validity:  not before Aug 31 20:01:48 2018, ok
             not after  Nov 29 20:01:48 2018, ok (expires in 32 days)
  serial:    03:9b:51:0b:e6:d6:ac:72:31:4a:0e:32:22:53:1f:ee:8d:0a
  altNames:  v.bougakov.com
  flags:     serverAuth clientAuth
  OCSP URIs: http://ocsp.int-x3.letsencrypt.org
  certificatePolicies:
             2.23.140.1.2.1
             1.3.6.1.4.1.44947.1.1.1
             CPS: http://cps.letsencrypt.org
  authkeyId: a8:4a:6a:63:04:7d:dd:ba:e6:d1:39:b7:a6:45:65:ef:f3:a8:ec:a1
  subjkeyId: 29:a0:8d:ac:f3:b2:b4:c6:31:21:92:28:93:bc:3e:f2:c9:b1:6e:15
  pubkey:    RSA 4096 bits
  keyid:     a4:87:05:63:18:0a:42:65:b8:93:1e:ed:a0:af:96:e8:85:4f:a6:72
  subjkey:   29:a0:8d:ac:f3:b2:b4:c6:31:21:92:28:93:bc:3e:f2:c9:b1:6e:15

I have copied all possible certificates from remote machine into /etc/ipsec.d/certs. I have also downloaded root certificate from https://letsencrypt.org/certificates/ and placed them into /etc/ipsec.d/cacerts but with zero effect - it seems that DST_Root_CA_X3.pem is simply ignored.

On Android client the OS somehow manages to obtain the root certificate by itself. What needs to be done on *nix client to make it aware of the root certificate? Thank you.

===

The full log on the client is:

Oct 27 22:55:30 charon
11[ENC] generating IKE_AUTH request 1 [ IDi IDr CPRQ(ADDR DNS) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
Oct 27 22:55:30 charon
11[NET] sending packet: from 95.84.168.236[4500] to 195.201.92.0[4500] (259 bytes)
Oct 27 22:55:30 charon
10[NET] received packet: from 195.201.92.0[4500] to 95.84.168.236[4500] (1248 bytes)
Oct 27 22:55:30 charon
10[ENC] parsed IKE_AUTH response 1 [ EF(1/3) ]
Oct 27 22:55:30 charon
10[ENC] received fragment #1 of 3, waiting for complete IKE message
Oct 27 22:55:30 charon
16[NET] received packet: from 195.201.92.0[4500] to 95.84.168.236[4500] (1248 bytes)
Oct 27 22:55:30 charon
16[ENC] parsed IKE_AUTH response 1 [ EF(2/3) ]
Oct 27 22:55:30 charon
16[ENC] received fragment #2 of 3, waiting for complete IKE message
Oct 27 22:55:30 charon
12[NET] received packet: from 195.201.92.0[4500] to 95.84.168.236[4500] (1241 bytes)
Oct 27 22:55:30 charon
12[ENC] parsed IKE_AUTH response 1 [ EF(3/3) ]
Oct 27 22:55:30 charon
12[ENC] received fragment #3 of 3, reassembling fragmented IKE message
Oct 27 22:55:30 charon
12[ENC] parsed IKE_AUTH response 1 [ IDr CERT CERT AUTH EAP/REQ/ID ]
Oct 27 22:55:30 charon
12[IKE] received end entity cert "CN=v.bougakov.com" 
Oct 27 22:55:30 charon
12[IKE] received issuer cert "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" 
Oct 27 22:55:30 charon
12[CFG] using certificate "CN=v.bougakov.com" 
Oct 27 22:55:30 charon
12[CFG] using untrusted intermediate certificate "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" 
Oct 27 22:55:30 charon
12[CFG] checking certificate status of "CN=v.bougakov.com" 
Oct 27 22:55:30 charon
12[CFG] ocsp response correctly signed by "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" 
Oct 27 22:55:30 charon
12[CFG] ocsp response is valid: until Nov 03 21:00:00 2018
Oct 27 22:55:30 charon
12[CFG] using cached ocsp response
Oct 27 22:55:30 charon
12[CFG] certificate status is good
Oct 27 22:55:30 charon
12[CFG] no issuer certificate found for "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" 
Oct 27 22:55:30 charon
12[CFG] issuer is "O=Digital Signature Trust Co., CN=DST Root CA X3" 
Oct 27 22:55:30 charon
12[IKE] no trusted RSA public key found for 'v.bougakov.com'
Oct 27 22:55:30 charon
12[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]

The openssl s_client -connect v.bougakov.com:443 -servername v.bougakov.com command on a client returns:

CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = v.bougakov.com
verify return:1
---
Certificate chain
 0 s:/CN=v.bougakov.com
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHBzCCBe+gAwIBAgISA5tRC+bWrHIxSg4yIlMf7o0KMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xODA4MzEyMDAxNDhaFw0x
[skipped]
1rfavu2l9hM5ApUNHmNP0wEM42jrvj34Jv4wVMYBgrK15aRWgIeV5fwjhhPhzUjy
SLm6xG67DBBvr6Tg7XzkeY38bUIExkAzQ87i
-----END CERTIFICATE-----
subject=/CN=v.bougakov.com
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3926 bytes and written 420 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 27C61A5C52CF9E35B40C75CB1A9F21D846CC095EFCF0D558E662DFA969E255BE
    Session-ID-ctx:
    Master-Key: 607B9FB68EFF293763D1DD24972AC512D184BB5C015EDDF5A8A3E49B42E9E8C6FAE8225B8C94BD3C404E81C077703EA9
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 86400 (seconds)
    TLS session ticket:
    0000 - 3f f4 37 5c f9 50 c0 40-c4 d1 be 69 21 93 0d 3d   ?.7\.P.@...i!..=
    0010 - 79 a1 17 bc e0 45 c4 01-dc e1 de e3 37 a2 79 93   y....E......7.y.
    0020 - 64 85 8f 71 94 a4 d8 8c-91 ea 1b eb c1 fa e5 ca   d..q............
    0030 - 53 c1 a4 0c 29 ab a3 76-db e8 b7 81 70 32 8f 17   S...)..v....p2..
    0040 - c0 eb ae 7c 76 73 42 8a-1b 74 01 6e 8f 47 fb d1   ...|vsB..t.n.G..
    0050 - a4 a6 60 c1 8f af 06 98-98 ed c8 f2 07 94 72 e0   ..`...........r.
    0060 - 98 a8 31 a0 90 7f f8 33-b5 fe 33 f2 82 3a 55 24   ..1....3..3..:U$
    0070 - b7 57 8f 7c a8 db 21 1c-7c 2f 16 a3 20 85 ae 6d   .W.|..!.|/.. ..m
    0080 - 0d b6 59 2e 14 8a 57 87-62 01 90 de b8 8f 1c 1d   ..Y...W.b.......
    0090 - 94 39 88 e4 d7 b5 06 4b-53 f0 51 aa e3 03 7a 45   .9.....KS.Q...zE
    00a0 - a9 60 7f f9 3d 9d 84 ef-84 2a 55 5c 0c 72 d7 a8   .`..=....*U\.r..
    00b0 - 0d 09 df 05 31 80 2b b0-8f 6a ae d1 40 b2 3f 27   ....1.+..j..@.?'

    Start Time: 1540682991
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

The /etc/ipsec.conf on a server reads:

config setup
        strictcrlpolicy=yes
        uniqueids=never
        charondebug="cfg 1, dmn 1, ike 0, net 0" 
conn roadwarrior
        auto=add
        compress=no
        type=tunnel
        keyexchange=ikev2
        fragmentation=yes
        forceencaps=yes
        ike=aes256gcm16-prfsha256-ecp521,aes256-sha256-ecp384
        esp=aes256gcm16-ecp384,aes256gcm16-sha256-ecp384,aes256gcm16-sha256!
        dpdaction=clear
        dpddelay=35s
        rekey=no
        left=%any
        leftid=@v.bougakov.com
        leftcert=cert.pem
        leftsendcert=always
        leftsubnet=0.0.0.0/0,::/0
        right=%any
        rightid=%any
        rightauth=eap-mschapv2
        eap_identity=%any
        rightsendcert=never
        rightsourceip=10.19.48.0/24,fd9d:bc11:4020::/48
        rightdns=172.16.0.1

The /etc/ipsec.conf on a client reads:

config setup
        strictcrlpolicy=yes
        uniqueids = never

conn ikev2vpn
        ikelifetime=3h
        compress=no
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev2
        fragmentation=yes
        ike=aes256gcm16-prfsha256-ecp521,aes256-sha256-ecp384
        #ike=aes256gcm16-prfsha384-ecp521!
        esp=aes256gcm16-ecp384,aes256gcm16-sha256-ecp384,aes256gcm16-sha256!
        #esp=aes256gcm16-ecp521!
        leftsourceip=%config
        leftauth=eap-mschapv2
        eap_identity=keenetic
        right=v.bougakov.com
        rightauth=pubkey
        rightid=@v.bougakov.com
        rightsubnet=0.0.0.0/0
        auto=start 

The /etc/ipsec.secrets on a client reads:

test   %any : EAP "redacted"

just as /etc/ipsec.secrets on a server:

v.bougakov.com : RSA "privkey.pem" 
test   %any : EAP "redacted"

History

#1 Updated by Alexander B about 1 month ago

On Android there are no issues:

Oct 28 02:55:59 16[IKE] received end entity cert "CN=v.bougakov.com" 
Oct 28 02:55:59 16[IKE] received issuer cert "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" 
Oct 28 02:56:00 16[CFG]   using certificate "CN=v.bougakov.com" 
Oct 28 02:56:00 16[CFG]   using untrusted intermediate certificate "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" 
Oct 28 02:56:00 16[CFG]   using trusted ca certificate "O=Digital Signature Trust Co., CN=DST Root CA X3" 
Oct 28 02:56:00 16[CFG]   reached self-signed root ca with a path length of 1
Oct 28 02:56:00 16[IKE] authentication of 'v.bougakov.com' with RSA_EMSA_PKCS1_SHA2_384

also there are no issues with this setup on Windows 10 and iOS

#2 Updated by Alexander B about 1 month ago

I have checked the certificate using ipsec pki and it also returns an error on both server and client:

 ipsec pki --verify --in /etc/ipsec.d/certs/cert.pem --cacert /etc/ipsec.d/cacerts/chain.pem
  using certificate "CN=v.bougakov.com" 
  using trusted intermediate ca certificate "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" 
no issuer certificate found for "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" 
certificate untrusted

What puzzles me is that server works nicely and serves incoming connections with the very same certificate files, but the client fails. I also can't find any hints on how to deploy updated certificates from Let's encrypt to the client. Android, iOS and Windows 10 clients obtain new certificates automatically online, but what how should the strongswan client be configured to get them on the *nix box (router)?

Many thanks in advance for helping to figure it out.

#3 Updated by Alexander B about 1 month ago

It appears that I've solved this by adding symlink on the client:

ln -s /etc/ssl/certs /etc/ipsec.d/cacerts

so certificate passes verification:

ipsec pki --verify --in /opt/etc/ipsec.d/certs/cert.pem
no issuer certificate found for "CN=v.bougakov.com" 
  issuer is "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" 
  using trusted certificate "CN=v.bougakov.com" 
certificate trusted, lifetimes valid

#4 Updated by Alexander B about 1 month ago

Yet client still fails:

13[IKE] establishing CHILD_SA ikev2vpn{1}
13[ENC] generating IKE_AUTH request 1 [ IDi CERTREQ IDr CPRQ(ADDR DNS) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
13[ENC] splitting IKE message with length of 2904 bytes into 3 fragments
13[ENC] generating IKE_AUTH request 1 [ EF(1/3) ]
13[ENC] generating IKE_AUTH request 1 [ EF(2/3) ]
13[ENC] generating IKE_AUTH request 1 [ EF(3/3) ]
13[NET] sending packet: from 95.84.168.236[4500] to 195.201.92.0[4500] (1248 bytes)
13[NET] sending packet: from 95.84.168.236[4500] to 195.201.92.0[4500] (1248 bytes)
13[NET] sending packet: from 95.84.168.236[4500] to 195.201.92.0[4500] (534 bytes)
14[NET] received packet: from 195.201.92.0[4500] to 95.84.168.236[4500] (1248 bytes)
14[ENC] parsed IKE_AUTH response 1 [ EF(1/3) ]
14[ENC] received fragment #1 of 3, waiting for complete IKE message
14[NET] received packet: from 195.201.92.0[4500] to 95.84.168.236[4500] (1248 bytes)
14[ENC] parsed IKE_AUTH response 1 [ EF(2/3) ]
14[ENC] received fragment #2 of 3, waiting for complete IKE message
16[NET] received packet: from 195.201.92.0[4500] to 95.84.168.236[4500] (1241 bytes)
16[ENC] parsed IKE_AUTH response 1 [ EF(3/3) ]
16[ENC] received fragment #3 of 3, reassembling fragmented IKE message
16[ENC] parsed IKE_AUTH response 1 [ IDr CERT CERT AUTH EAP/REQ/ID ]
16[IKE] received end entity cert "CN=v.bougakov.com" 
16[IKE] received issuer cert "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" 
16[CFG]   using certificate "CN=v.bougakov.com" 
16[CFG]   using untrusted intermediate certificate "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" 
16[CFG] checking certificate status of "CN=v.bougakov.com" 
16[CFG]   requesting ocsp status from 'http://ocsp.int-x3.letsencrypt.org' ...
16[CFG]   ocsp response correctly signed by "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" 
16[CFG]   ocsp response is valid: until Nov 03 21:00:00 2018
16[CFG] certificate status is good
16[CFG]   using trusted ca certificate "O=Digital Signature Trust Co., CN=DST Root CA X3" 
16[CFG] checking certificate status of "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" 
16[CFG] ocsp response verification failed, no signer certificate 'C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3' found
16[CFG]   requesting ocsp status from 'http://isrg.trustid.ocsp.identrust.com' ...
16[CFG]   ocsp response correctly signed by "C=US, O=Digital Signature Trust, OU=DST, CN=DST CA X3 OCSP Signer, E=pki-ops@IdenTrust.com" 
16[CFG]   ocsp response is valid: until Nov 01 22:09:18 2018
16[CFG] certificate status is good
16[CFG] certificate policy 2.23.140.1.2.1 for 'CN=v.bougakov.com' not allowed by trustchain, ignored
16[CFG] certificate policy 1.3.6.1.4.1.44947.1.1.1 for 'CN=v.bougakov.com' not allowed by trustchain, ignored
16[CFG]   reached self-signed root ca with a path length of 1
16[IKE] authentication of 'v.bougakov.com' with RSA_EMSA_PKCS1_SHA2_384 successful
16[IKE] server requested EAP_IDENTITY (id 0x00), sending '[redacted]'
16[ENC] generating IKE_AUTH request 2 [ EAP/RES/ID ]
16[NET] sending packet: from 95.84.168.236[4500] to 195.201.92.0[4500] (74 bytes)
06[NET] received packet: from 195.201.92.0[4500] to 95.84.168.236[4500] (97 bytes)
06[ENC] parsed IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ]
06[IKE] server requested EAP_MSCHAPV2 authentication (id 0x1B)
06[ENC] generating IKE_AUTH request 3 [ EAP/RES/MSCHAPV2 ]
06[NET] sending packet: from 95.84.168.236[4500] to 195.201.92.0[4500] (128 bytes)
11[NET] received packet: from 195.201.92.0[4500] to 95.84.168.236[4500] (114 bytes)
11[ENC] parsed IKE_AUTH response 3 [ EAP/REQ/MSCHAPV2 ]
11[IKE] EAP-MS-CHAPv2 failed with error ERROR_AUTHENTICATION_FAILURE: '(null)'
11[IKE] EAP_MSCHAPV2 method failed
11[ENC] generating INFORMATIONAL request 4 [ N(AUTH_FAILED) ]
11[NET] sending packet: from 95.84.168.236[4500] to 195.201.92.0[4500] (65 bytes)

#5 Updated by Noel Kuntze about 1 month ago

  • Category changed from starter to configuration
  • Assignee set to Noel Kuntze
  • Priority changed from Low to Normal
11[ENC] parsed IKE_AUTH response 3 [ EAP/REQ/MSCHAPV2 ]
11[IKE] EAP-MS-CHAPv2 failed with error ERROR_AUTHENTICATION_FAILURE: '(null)'

That error is from the server.

no issuer certificate found for "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" 
certificate untrusted

Evidently tells you that the issuer certificate of the Let's Encrypt CA isn't available. That'd be the DST CA.

For authentication to be successful, at least the server side has to have the complete chain from the root certificate to its own certificate. The client has to have the same for its own certificate, if it uses one, and in either case, at least the root CA of the server's certificate. That is explicitely not always the issuing CA of the server's CA. As you can see in your own use case, the issuing CA of the server's certificate is the "Let's Encrypt Authority X3", which is a sub CA (intermediate CA) that was issued by the DST Root CA X3 of Digital Signature Trust Co.

#6 Updated by Alexander B about 1 month ago

Thank you. I did that myself, but it didn't help first.

After your comment I figured I needed to explicitly run ipsec rereadall to apply the change.

#7 Updated by Noel Kuntze about 1 month ago

  • Status changed from New to Closed
  • Resolution set to No change required

If you only changed ipsec.d/cacerts, running `ipsec stroke rereadcacerts` is sufficient.

Also available in: Atom PDF