On Fri, 8 Mar 2019, LAURIA Giuseppe wrote:
The other end's CERT payload did not contain an EE certificate? Looks like they
are sending a bad certificate chain.
But when I look into the other servers database it looks like to be "good":
Yes:
In the right server it is defined:
rightcert="ivoryserver"
In the left server it is named:
rightcert="lxfapp31.dev.axa-ch.intraxa" ( see below ) should I avoid
this ? Did I define too many attributes ? In older vesion it worked.
The name (or "friendly_name") is not relevant. But as said, NSS is very
picky about EKU's and SAN's and selfsigned certs and you have to get those
right.
The newer code uses NSS instead of custom X509 validation code. NSS is more
secure, and likely more strict. Perhaps you had the cert hardcoded and the CERT
payload wasn't used before? And now we reject the hardcoded certificate because
we are more strict on the CERT payload (even if we don't need the CERT payload
due to hardcoded cert/pubkey ?)
That's a theory anyway.
Do not understand where I can fix something here.
We wrote a fallback, so the NSS TLS profile is used as fallback for the
NSS IPsec profile. That should solve any regression for the time being.
It is in git master, so if you pull that code you should have the fix.
Otherwise, you can try and apply the patch:
https://github.com/libreswan/libreswan/commit/7de7d5cdb6717101b8161891ed4344dfd32f5e4c
The other end should send its EE-cert as CERT payload. It may send intermediate
CA's as well (and we support receiving those as proper CERT payloads or the
broken microsoft pkcs#7 formatted ones).
How can I do this ? ( I'm the other side also here in this case )
You can try setting leftsendcert=always and righsendcert=always, but
those settings should not matter if you are loading both certs on both
ends (eg if you have leftcert= and rightcert= on both ends)
Certificate Left server in db:
[root@DDAA2053 ipsec.d]# certutil -d sql:. -V -n
ivorycloudmaint1.dev.axa-ch.intraxa -u C
certutil: certificate is valid
[root@DDAA2053 ipsec.d]# certutil -d sql:. -O -n
ivorycloudmaint1.dev.axa-ch.intraxa
"C=FR,CN=AXA-Enterprise-Root-CA,O=GIE AXA"
[C=FR,CN=AXA-Enterprise-Root-CA,O=GIE AXA]
"C=FR,CN=AXA-Issuing-CA-PR1,O=GIE AXA" [C=FR,CN=AXA-Issuing-CA-PR1,O=GIE AXA]
"ivorycloudmaint1.dev.axa-ch.intraxa"
[CN=ivorycloudmaint1.dev.axa-ch.intraxa,OU=applid:COM-728,OU=appl:ivory,OU=tenantStage:maint,OU=axans:ch-ivory,O=axa-ch,C=CH]
You can try setting sendca=all if you are using intermediate CA's not in
the NSS database.
also, all your CA certificates in the NSS db must have the trust flags
set (CT,,) or else they do not count as a valid CA.
rightprotoport=tcp/8080
If you set protoport on one side, you should set it on the other too.
If the traffic uses source port 8080 and destination port 8080, you
should add:
leftprotoport=tcp/8080
If it uses a random high port, then you probably need to create two
conns, one from tcp/8080 to tcp/0 and one from tcp/0 to tcp/8080
104 "cloud_core_tunnel" #9: STATE_MAIN_I1: initiate
106 "cloud_core_tunnel" #9: STATE_MAIN_I2: sent MI2, expecting MR2
002 "cloud_core_tunnel" #9: I am sending my cert
002 "cloud_core_tunnel" #9: I am sending a certificate request
108 "cloud_core_tunnel" #9: STATE_MAIN_I3: sent MI3, expecting MR3
002 "cloud_core_tunnel" #9: Peer ID is ID_DER_ASN1_DN: 'C=CH, O=axa-tech-ch,
OU=axans:ch-ivory, OU=tenantStage:maint, OU=pltStage:dev, OU=appl:ivory,
OU=applid:COM-728, CN=ivorylbmaint.dev.axa-ch.intraxa'
002 "cloud_core_tunnel" #9: X509: no EE-cert in chain!
So I think you are using selfsigned certificates. If you don't want to
use a CA, you should use raw keys and not selfsigned certs.
eg:
ipsec newhostkey --output /etc/ipsec.secrets
ipsec showhostkey --left --ckaid XXXX
And configure leftrsasigkey/rightrsasigkey without using any leftcert/rightcert.
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
