OE client mistakenly sees peer id as ID_NULL type ?

[letoams]

Jul 9 23:19:37.119069: "private-or-clear#193.110.157.0/24"[1] ...193.110.157.131 #4: certificate verified OK: CN=letsencrypt.libreswan.org
Jul 9 23:19:37.119253: "private-or-clear#193.110.157.0/24"[1] ...193.110.157.131 #4: Unhandled ID type 13: ID_NULL
Jul 9 23:19:37.119256: "private-or-clear#193.110.157.0/24"[1] ...193.110.157.131 #4: Peer public key SubjectAltName does not match peer ID for this connection
Jul 9 23:19:37.119259: "private-or-clear#193.110.157.0/24"[1] ...193.110.157.131 #4: X509: CERT payload does not match connection ID
Jul 9 23:19:37.119410: "private-or-clear#193.110.157.0/24"[1] ...193.110.157.131 #4: deleting state (STATE_PARENT_I2) aged 0.208s and NOT sending notification

It seems to think the peer is using ID_NULL ?

note the server side is happy:

Jul 9 23:36:12.630733: "clear-or-private#0.0.0.0/0"[2] ...206.248.139.105 #2: processing encrypted IKE_AUTH request: SK (message arrived 0 seconds ago)
Jul 9 23:36:12.632952: "clear-or-private#0.0.0.0/0"[2] ...206.248.139.105 #2: processing decrypted IKE_AUTH request: SK{IDi,IDr,AUTH,CP,SA,TSi,TSr}
Jul 9 23:36:12.633137: "clear-or-private#0.0.0.0/0"[2] ...206.248.139.105 #2: Authenticated using authby=null
Jul 9 23:36:12.661672: "clear-or-private#0.0.0.0/0"[2] ...206.248.139.105===100.64.0.1/32: constructed local ESP/AH proposals for clear-or-private#0.0.0.0/0 (IKE_AUTH responder matching remote ESP/AH proposals): 1:ESP:ENCR=AES_GCM_C_256;INTEG=NONE;ESN=DISABLED 2:ESP:ENCR=AES_GCM_C_128;INTEG=NONE;ESN=DISABLED 3:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128;ESN=DISABLED 4:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128;ESN=DISABLED 5:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA1_96;ESN=DISABLED (default)
Jul 9 23:36:12.710802: "clear-or-private#0.0.0.0/0"[2] ...206.248.139.105===100.64.0.1/32 #3: negotiated connection [193.110.157.131-193.110.157.131:0-65535 0] -> [100.64.0.1-100.64.0.1:0-65535 0]

and server definitely does not send ID_NULL type, but RSA

Jul 9 23:36:12.633317: | ****emit IKEv2 Identification - Responder - Payload:
Jul 9 23:36:12.633323: | next payload type: ISAKMP_NEXT_v2NONE (0x0)
Jul 9 23:36:12.633328: | flags: none (0x0)
Jul 9 23:36:12.633332: | ID type: ID_DER_ASN1_DN (0x9)

Jul 9 23:36:12.637763: | ****emit IKEv2 Authentication Payload:
Jul 9 23:36:12.637767: | next payload type: ISAKMP_NEXT_v2CP (0x2f)
Jul 9 23:36:12.637772: | flags: none (0x0)
Jul 9 23:36:12.637776: | auth method: IKEv2_AUTH_RSA (0x1)

So why is the client thinking the peer used ID_NULL? This is a software bug (not a configuration bug)

[Rishabh04-02]

and server definitely does not send ID_NULL type, but RSA

Yes, the server always sends RSA.

So why is the client thinking the peer used ID_NULL? This is a software bug (not a configuration bug)

I'm not sure why the client sees ID_NULL. Software bug as in Libreswan or This project?

[Rishabh04-02]

@letoams In my case when I try to connect, the client is showing that the server is Authenticated using RSA

002 "private-or-clear#193.110.157.131/32"[1] ...193.110.157.131 #2: certificate verified OK: CN=letsencrypt.libreswan.org
003 "private-or-clear#193.110.157.131/32"[1] ...193.110.157.131 #2: Authenticated using RSA
002 "private-or-clear#193.110.157.131/32"[1] ...193.110.157.131 #2: negotiated connection [142.93.216.119-142.93.216.119:0-65535 0] -> [193.110.157.131-193.110.157.131:0-65535 0]