Tuesday, July 30, 2024

Re: iked authentication logging ?

On Tue, Jul 30, 2024 at 11:39:39PM -0000, Stuart Henderson wrote:
> On 2024-07-30, J Doe <general@nativemethods.com> wrote:
> > As a result with continuing to experiment with my configuration, I ran
> > into a new issue. I followed the instructions in the OpenBSD FAQ[0] for
> > an X.509 configuration - in particular the following (with hostnames for
> > my server and Mac):
> >
> > server1# ikectl ca vpn certificate client1.domain create
> > server1# cp /etc/ssl/vpn/client1.domain.crt /etc/iked/certs/
> > server1# ikectl ca vpn certificate client1.domain export
>
> BTW this is a shortcut that ikectl implements to make things easy,
> although it does mean that the client's "private" key actually ends
> up on the server.
>
> The traditional way of doing this is exactly like an X509 cert for a
> web server, i.e. the client generates a private key and cert signing
> request, the key is never transferred off the machine, only the CSR
> which is taken to the CA. The CA then uses that to produce a cert
> which is signed by the CA and sent back.
>
> See the X.509 AUTHENTICATION section in isakmpd(8) for some gory
> details which are mostly hidden if you use "ikectl ca".

It's worth reading and understanding the process even you continue using
ikectl to generate the certs.

We also published some info on this a couple of years ago:

https://research.exoticsilicon.com/series/reckless_guide_to_openbsd/keys_and_certificates

There is a shell script at the end of that article which generates keys and
certs in a similar way to 'ikectl ca', but using the openssl command line
tool. This might make it easier to look inside the process and adapt it for
your own needs.

> > server1# tar -C /tmp -xzf client1.domain.tgz *pfx
> > server1# cp /tmp/export/client1.domain.pfx \
> > /var/www/htdocs/client1.domain.pfx
> >
> > ...so on my OpenBSD server I have the client's X.509 certificate and the
> > CA certificate at: /etc/iked/certs.
> >
> > I then removed the _client_ certificate from this location on the server
> > and attempted connecting from the Mac and it authenticated.
> >
> > My new question is - shouldn't the server reject a X.509 authentication
> > attempt if the _client_ certificate is not on the server ?
>
> No, that's not how it is expected to work, you don't need the client cert
> on the server, just a way to validate that it's correct (by checking the
> CA's signature and, IIUC, checking the subjectAltName against srcid).

Yep, the srcid should be present in the SAN field, but note that if you look
at iked logs, especially if it's invoked in verbose mode, you'll see
references to certs based on their Common Name field in diagnostic and error
messages.

This actually makes sense, because the CN should ideally be a unique
identifier amongst the certs you have loaded, whereas the SANs can obviously
include multiple hostnames and literal IP addresses. So for error message
reporting the CN is more useful.

But authentication, (at least with iked), doesn't really care about the CN.

No comments:

Post a Comment