On 2024-07-30 18:13, J Doe wrote:
On 2024-07-25 03:11, Crystal Kolipe wrote:
On Wed, Jul 24, 2024 at 06:20:26PM -0400, J Doe wrote:
My hypothesis is that iked does not name an identity because this is
certificate based authentication vs. MSCHAPv2 for EAP authentication
which would provide an identity (ie: a username).
Is that correct ?
No.
The identity that would be printed is the srcid of the peer. By
default this
would be it's hostname, and should be present in the SAN field of any
certificate used for iked.
You can see that error message displayed both with and without a named
ID when
using certificate authentication, depending on the cause of the error.
It will also display without an ID even if one if known, if the
printing code
in iked fails some internal consistency checks, (which is unlikely but
possible).
Hi Crystal,
Thank you for your reply.
I had a chance to experiment a bit with this, this past weekend. The
client OS was mac OS Sonoma (macOS 14.5).
Firstly, I configured my Mac to connect to my OpenBSD server with a
local ID of nothing (empty string), using shared secret and
username/password authentication.
As my OpenBSD server is configured for x.509 certificate authentication,
these two logon attempts were rejected and the OpenBSD server logs noted
what I mentioned in my original message: "authentication failed for"
without listing an identity.
Secondly, I then repeated this but specified an arbitrary identity for
the local ID (ie: whatever.com). This also produced the same log
results: "authentication failed for" without listing an identity.
Lastly, I repeated this with the local ID on the Mac set to the same
value as the: dstid in my: iked.conf file:
kev2 "VPN" passive ipcomp tunnel esp \
from any to dynamic \
local egress peer any \
srcid server.home.arpa \
dstid client.home.arpa \
config address 10.0.5.0/24 \
tag "ROADW"
... so the local ID on the Mac was: "client.home.arpa". I then
attempted to logon with a shared secret and username/password and noted
the following in my logs: "authentication failed for FQDN/client.home.arpa"
This replicated what you said in your reply:
"No. The identity that would be printed is the srcid of the peer"
... which clears up my original question - thank you!
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
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 ? I was under
the impression that X.509 authentication with iked would be the same as
SSH - that the _client_ public key MUST be on the server (as stored in
the certificate) ?
Thanks,
- J
Links:
======
[0] https://www.openbsd.org/faq/faq17.html#authx509
Hi again Crystal and list,
Apologies - near the end of my last message where I wrote:
> ...so on my OpenBSD server I have the client's X.509 certificate
and the
>> CA certificate at: /etc/iked/certs.
I meant that I have the client's certificate and the _server_
certificate under: /etc/iked/certs whereas the CA certificate is under:
/etc/iked/ca
- J
