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.
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.
@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?
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.
Putting a symlink to the chain.pem file into the "cacerts" folder and removing the old intermediate file did the trick! Thanks a lot!
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?
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?
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?
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.
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.
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.
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)?
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.
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.
I'm pretty sure you would need to use OpenVPN to get the cert/chain used.
Well, without a hostname to connect to, I can't test anything anyway
Yeah, thanks for the thought, but I'm not going to post VPN domains here
Is there a certificate further up the chain that I could install to avoid this issue in future if they fail at the next renewal?
Allister999 could you confirm that you're definitely not having the problem outlined in the linked issue ISRG Root lazy loading problem + missing from (random) updated Windows 10 versions
It sounds like it may be possible this is the underlying problem you're having and it also seems some people in this thread may not be aware of this as well.
It's hard for me to state where the issue is precisely. We had an issue on renewal of certificate that meant only Windows 10 machines failed to connect to our VPN service until we installed the renewed certificate locally. This was multiple W10 machines on multiple sites. No MacOS or IOS device experienced a connection issue. If you have any tests that I can try and narrow it down.
Confirms rasdial lazy-load of root issue in the other thread.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.