[Swan] [EXTERNAL] Re: AW: INVALID_ID_INFORMATION

[LAURIA Giuseppe]

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 at lxfapp31 ipsec.d]# certutil -d sql:. -V -n ivoryserver -u C
certutil: certificate is valid

[root at 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 at 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 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]

[root at DDAA2053 ipsec.d]#




Certificate Right server in db:

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