[Swan] [EXTERNAL] Re: AW: INVALID_ID_INFORMATION

Paul Wouters paul at nohats.ca
Fri Mar 8 16:53:54 UTC 2019


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 at DDAA2053 ipsec.d]# certutil -d sql:. -V -n ivorycloudmaint1.dev.axa-ch.intraxa -u C
> certutil: certificate is valid
> [root at 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


More information about the Swan mailing list