On 2021/05/14 21:14, Tobias Heider wrote:
> On Thu, May 13, 2021 at 02:39:37PM +0900, Katsuhiro Ueno wrote:
> > Hi,
> >
> > I would be happy if iked(8) supports intermediate CAs and sends the
> > entire certificate chain to the clients. The diff attached adds
> > supports for intermediate CAs and multiple CERT payloads to iked(8).
> >
> > What I would like to do is to use a LetsEncrypt certificate as a
> > server certificate of IKEv2 EAP and establish VPN connections with
> > Windows clients. However, I could not complete it because of the
> > following reasons.
> > * LetsEncrypt server certificate is issued by an intermediate CA
> > and therefore the certificate of the intermediate CA is needed to
> > check the validity of the server certificate.
> > * Windows expects the IKEv2 server to send the intermediate CA's
> > certificate in addition to the server certificate to check the
> > validity.
> > * On the other hand, iked(8) is not capable of dealing with
> > certificate chains and sending multiple certificates (multiple
> > CERT payloads) to the clients.
> > Consequently, Windows fails to verify the certificate and therefore
> > VPN connection cannot be established.
> >
> > To overcome this, I added an (ad-hoc) support for certificate chain
> > and multiple CERT payloads. The diff attached is the changes that I
> > made. It works fine for me but I am not sure whether or not it works
> > for everyone and everywhere. Tests and comments are greatly
> > appreciated.
> >
> > Many thanks,
> > Katsuhiro Ueno
>
> Hi Katsuhiro,
>
> thank you for the diff!
> As Stuart said this is a very welcome addition and the diff looks good to me.
>
> Unfortunately I don't have a Windows machine here to test with, so it would be
> nice if anyone reading this could give it a try on their Windows setup.
>
> I will try running a few more tests with Strongswan clients and commit it
> once I'm sure everything still works.
>
> - Tobias
>
Tested with Android strongswan. If I write the intermediate and
root certificates to ca/ca.crt and the server certificate to
certs/$HOSTNAME.crt then I'm able to connect.
I haven't tested Windows yet, I'll try to locate a machine to test with
at the weekend.
The certificate arrangement is a little awkward to work with typical
ACME infrastructure used with standard TLS servers:
For a standard server the root certificate would not normally need to
be present at all; only server and intermediate certs are needed (though
possibly this may be different for IKEv2). As such, ACME clients don't
normally fetch this certificate so it must be retrieved separately.
Also typically for a TLS server, any intermediates would be stored
alongside the server certificate (fullchain.pem in the usual acme-client
config). Storing that in a separate file isn't difficult ("chain" rather
than "full chain" for acme-client) but, combined with the above need
to store the CA in that same file, it does mean some extra fiddling is
required.
So to use this diff as-is with acme-client, something like this is needed
(I haven't tested the whole thing put together but I think it's right),
domain key "/etc/iked/private/local.key"
domain certificate "/etc/iked/certs/hostname.crt"
domain chain certificate "/etc/iked/ca/chain.crt"
<request cert>
ftp -o /etc/iked/ca/ca.p7c $(openssl x509 -in /etc/iked/ca/chain.crt -text
-noout | grep 'CA Issuers' | cut -d: -f2-)
(cat /etc/iked/ca/chain.crt; openssl pkcs7 -inform DER -in /etc/iked/ca/ca.p7c
-print_certs) > /etc/iked/ca/ca.crt
At least it's going to need some doc to show what goes where. But it
would be much simpler to work with if it would at least accept "full
chain" in the single certs/hostname.crt file.
