Hi Paul.
>>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":
On the right server:
[root@lxfapp31 ipsec.d]# certutil -d sql:. -V -n ivoryserver -u C
certutil: certificate is valid
[root@lxfapp31 ipsec.d]# certutil -d sql:. -O -n ivoryserver
"AXA-Enterprise-Root-CA" [C=FR,CN=AXA-Enterprise-Root-CA,O=GIE AXA]
"AXA-Issuing-CA-PR1 - GIE AXA" [C=FR,CN=AXA-Issuing-CA-PR1,O=GIE AXA]
"ivoryserver"
[CN=ivorylbmaint.dev.axa-ch.intraxa,OU=applid:COM-728,OU=appl:ivory,OU=pltStage:dev,OU=tenantStage:maint,OU=axans:ch-ivory,O=axa-tech-ch,C=CH]
[root@lxfapp31 ipsec.d]#
>>>>>>Looks like you either hardcoded the certificate using rightcert= or you
>>>>>>used a rightrsasigkey= ?
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 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.
>>>>>>>>>>>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 )
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]
[root@DDAA2053 ipsec.d]#
Certificate Right server in db:
[root@DDAA2053 ipsec.d]# certutil -d sql:. -V -n lxfapp31.dev.axa-ch.intraxa -e
-u C
certutil: certificate is valid
[root@DDAA2053 ipsec.d]# certutil -d sql:. -O -n lxfapp31.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]
"lxfapp31.dev.axa-ch.intraxa"
[CN=ivorylbmaint.dev.axa-ch.intraxa,OU=applid:COM-728,OU=appl:ivory,OU=pltStage:dev,OU=tenantStage:maint,OU=axans:ch-ivory,O=axa-tech-ch,C=CH]
[root@DDAA2053 ipsec.d]#
I have defined :
In left server:
conn cloud_core_tunnel
left=ivorycloudmaint1.dev.axa-ch.intraxa
leftid=%fromcert
leftcert="ivorycloudmaint1.dev.axa-ch.intraxa"
leftrsasigkey=%cert
leftsendcert=always
right=lxfapp31.dev.axa-ch.intraxa
#
rightid="CN=lxfapp31.dev.axa-ch.intraxa,OU=applid:COM-728,OU=appl:ivory,OU=pltStage:dev,OU=tenantStage:maint,OU=axans:ch-ivory,O=axa-tech-ch,C=CH"
#
rightid="CN=ivorylbmaint.dev.axa-ch.intraxa,OU=applid:COM-728,OU=appl:ivory,OU=pltStage:dev,OU=tenantStage:maint,OU=axans:ch-ivory,O=axa-tech-ch,C=CH"
rightid=%fromcert
rightcert="lxfapp31.dev.axa-ch.intraxa"
rightprotoport=tcp/8080
rightrsasigkey=%cert
#auto=start
authby=rsasig
type=transport
ike=aes256-sha2-modp2048
phase2=esp
phase2alg=aes_gcm-null
salifetime=240m
fragmentation=yes
In right server:
conn cloud_core_tunnel
# left=ddaa2053.ppprivmgmt.intraxa
left=ivorycloudmaint1.dev.axa-ch.intraxa
# leftid="CN=ivorycloudmaint1.dev.axa-ch.intraxa"
leftid=%fromcert
leftcert="ddaa2053.ppprivmgmt.intraxa"
leftrsasigkey=%cert
leftsendcert=always
right=lxfapp31.dev.axa-ch.intraxa
# right=ivorylbmaint.dev.axa-ch.intraxa
rightcert="ivoryserver"
rightprotoport=tcp/8080
rightrsasigkey=%cert
#auto=start
authby=rsasig
type=transport
ike=aes256-sha2-modp2048
phase2=esp
phase2alg=aes_gcm-null
salifetime=240m
fragmentation=yes
Still I get
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!
002 "cloud_core_tunnel" #9: X509: Certificate rejected for this connection
002 "cloud_core_tunnel" #9: X509: CERT payload bogus or revoked
218 "cloud_core_tunnel" #9: STATE_MAIN_I3: INVALID_ID_INFORMATION
002 "cloud_core_tunnel" #9: sending encrypted notification
INVALID_ID_INFORMATION to 10.152.119.60:500
Is it the certificate configured in the conf file wrong or the certificate sent
on the wire wrong ? Over which one is it complaining ?
Are there more tools to verify/troubleshoot cert is ok or not ok ? on both ends
?
Thank you very much.
Best.
Giuseppe
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
