On Wed, 15 Jul 2020, Balaji Thoguluva wrote:
The two are not related. The CERTREQ is just a "hint" for the other side
to pick its own CERT if it has more than one to choose from.
[Balaji] Yes, the other end does not send the certificate in the IKE_AUTH
response back to Libreswan and so Libreswan cannot validate the
"[email protected]" id and fails to establish a tunnel.
So the assumption is that a CERTREQ would make a difference, I'm not so sure.
Does the ID [email protected] appear as SAN on the certificate?
[Balaji] Yes, the ID appears as Subject Alternate Name on the certificate.
However as said in my previous response, the other end is not
sending the certificate in the IKE_AUTH response back.
I'm looking at the code that makes this decision.
If we are not the exchange initiator, we don't send one. Eg if they
initiate to you, then it is up to them to send a CERTREQ.
I just notice a bug where it only checks for RSA and not ECDSA, so if you
are using authby=ecdsa, this is causing libreswan to not send a certificate.
A patch for this I just pushed is:
diff --git a/programs/pluto/x509.c b/programs/pluto/x509.c
index 5fc7efdaf6..9ad46a6359 100644
--- a/programs/pluto/x509.c
+++ b/programs/pluto/x509.c
@@ -1289,9 +1289,8 @@ bool ikev2_send_certreq_INIT_decision(const struct state
*st,
const struct connection *c = st->st_connection;
- if (!(c->policy & POLICY_RSASIG)) {
- dbg("IKEv2 CERTREQ: policy does not have RSASIG: %s",
- prettypolicy(c->policy & POLICY_ID_AUTH_MASK));
+ if ((c->policy & POLICY_ID_AUTH_MASK) == POLICY_PSK || (c->policy &
POLICY_ID_AUTH_MASK) == POLICY_AUTH_NULL) {
+ dbg("IKEv2 CERTREQ: authby=secret and authby=null do not require
CERTREQ");
return FALSE;
}
Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
