Win10 doesn't connect to VPN after R3 transition

Help
1

I can confirm that this does cause issues, I have a Draytek firewall using a Let's Encrypt certificate for IKEV2 VPNs and the moment the certificate renewed on 18/12/2020 all Windows 10 machines stopped connecting to the VPNs. Apple devices were unaffected. Browsing to the firewall management website using HTTPS using Edge did not help but Edge did not complain about the certificate either.

I hadn't found this thread at that point so we eventually ended up installing the certificate on each machine to fix the issue.

2 Likes
2

@Alister999 If I understood this thread correctly, the issue is with the new ISRG Root X1 and not with the currently in use root DST Root CA X3. Do you already chain up to the ISRG Root X1 root certificate, if you're having problems already? If not, then there probably is something else happening, perhaps a missing intermediate certificate.

1 Like
3

My apologies if I've misunderstood or categorised my issue. It's not an area I'm expert in and there was little else that directly related to the issue I'd had.

1 Like
4

Welcome, Alister, and no need to apologize! It does sound like your issue is unrelated to the main content in this thread, though, as this thread is discussing upcoming changes (when we switch to providing certificates which chain up to our own ISRG Root X1 instead of up to DST Root CA X3), not discussing the past change which appears to have affected you (when we changed from using our X3 intermediate to our R3 intermediate). As such, I'm going to split this off into a separate thread, and hopefully you can get any help you need there!

3 Likes
5

Unfortunately I have the same issue. I'm using Strongswan on Ubuntu 18 with a Letsencrypt certificate, and after the latest renewal all Windows 10 clients can't connect anymore. iOS still works fine. Nothing else changed.
Are there any solutions or workarounds so far?

1 Like
6

@Carsten Is your intermediate certificate correct?

1 Like
7

@Osiris We are using this one for two years now:
https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem

Just reinstalled it to be sure, no difference.

8

Not surprisingly. That's the incorrect intermediate.

Never ever hardcode an intermediate certificate. Let your ACME client determine the correct one used to issue the end leaf certificate. Use that one.

2 Likes
9

@Osiris Thanks a lot for your help. Strongswan requires such a certificate in the "cacerts" folder, otherwise it doesn't work. Or what is the correct solution here?

1 Like
10

After each renewal, copy the intermediate certificate provided by your ACME client to the cacerts folder. Usually, an ACME client can automate running scripts after a renewal. Or use a symbolic link if strongSwan also accepts that.

2 Likes
11

Putting a symlink to the chain.pem file into the "cacerts" folder and removing the old intermediate file did the trick! Thanks a lot!

:+1:

3 Likes
12

OK, thanks for that

Does anyone know if this is a short term issue that will be fixed by a future patch from Microsoft or something that will need work when certificates are renewed?

13

Microsoft can't do anything about you including the wrong intermediate CA certificate in your VPN configuration. Your Let's Encrypt automation solution must account for changes in the intermediate certificate at any time.

Or am I misunderstanding the issue you're asking about?

3 Likes
14

The IKEV2 VPNs connect Windows 10 and MacOS clients to a Draytek box using a Let's Encrypt certificate did not require any certificates to be installed at the client end during commision. It was only after the certificate was renewed in mid December that the Windows 10 machines stopped working. So I'm not entirely sure how I installed the wrong intermediate CA certificate?

15

Can you check that the Draytek box is serving the proper cert+chain?

It is, in fact, the only thing that is known to have changed.

I don't know the case, but it is possible that the renewal did not go correctly and is the cause of the problem.

It is also possible that the renewal went perfectly and the problem is elsewhere.

2 Likes
16

And without a noticeable warning, I can't make any more edits for a few hours.
So here is the last update to the ^^^ post above:
[I'll have to go back and delete it, once I'm able to]

Can you check that the Draytek box is serving the proper cert+chain?

It is, in fact, the only thing that is known to have changed.

I don't know the case, but it is possible that the renewal did not go correctly and is the cause of the problem. Like: maybe new cert but old chain in use.

It is also possible that the renewal went perfectly and the problem is elsewhere.
Like: maybe your windows system doesn't know/trust the new intermediate/root in use.

1 Like
17

The system was setup in June and working until December, so there was one successful automatic certificate renewal before the issue occurred. I did try revoking and renewing the certificate manually on the Draytek before installing the certificate on all W10 machines. MacOS and iOS devices were unaffected.

Firefox and Edge are happy with the certificate but Chrome classes it as a deceptive site, if that helps at all.

18

Do you have a copy of the cert+chain that you installed?

Otherwise, do you have access to OpenSSL?
And does your VPN responde on any TCP port (like 500, 1723, 4500)?

1 Like
19

No certificate was installed at the client end until the December renewal. The Draytek end has a built-in LE process, I guess it's entirely possible that the changes at LE's end haven't been properly handled by Draytek.

IKE V2 is being used due to providing the best throughput/security combination for the device.

1 Like
20

That should be easily testible, but with IKE v2 I'm not sure if a simple openssl s_client hl-connect ... will suffice, like it does with HTTPS to check for the correct chain.

1 Like