I just ran a few tests, and i dont see this problem. I need to know what is in both sides NSS DB. Please run on both endpoints:

certutil -L -d sql:/etc/ipsec.d

(if the other end is not libreswan, I guess we can only assume it does the right thing)

If you can also set plutodebug=all and provide the log, that would be helpful

Clarify this issue:
Here is procedure:

NUT is a machine with RHEL6.8 installation, TN1 is a tester node with IOL USGv6 test software.

On NUT:
# certutil -L -d /etc/ipsec.d

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

NUT - IOL                                                    u,u,u
CA - IOL                                                     ,,   
iolintact - IOL                                              u,u,u


NUT(RHEL6.8)   TN1
(End-Node)   (End-Node)
¦               ¦
¦-------------->¦ IKE_SA_INIT request (HDR, SAi1, KEi, Ni)
¦               ¦ (Judgment #1)
¦<--------------¦ IKE_SA_INIT response (HDR, SAr1, KEr, Nr, CERTREQ)
¦               ¦ (Packet #1)
¦               ¦
¦-------------->¦ IKE_AUTH request (HDR, SK {IDi, CERT, AUTH, N, SAi2, TSi, TSr})
¦               ¦ (Judgment #2)
¦               ¦
V               V
N: USE_TRANSPORT_MODE

We failed at Judgment #2, the IKE_AUTH request should include an ID payload with ID_RFC822_ADDR(3)

Decrypted Data
  Contained Data
    Type Payload: Identification - Initiator (35)
      Next payload: Certificate (37)
      0... .... = Critical Bit: Not Critical
      Payload length: 23
      ID Type: ID_REC822_ADDR (3)      <-------- as expect
      Protocol ID : Unused
      Port: Unused
      Identificatoin Data: nut  <------------- as expect

But we got request with DER_ASN1_DN(9)

Decrypted Data
  Contained Data
    Type Payload: Identification - Initiator (35)
      Next payload: Certificate (37)
      0... .... = Critical Bit: Not Critical
      Payload length: 90
      ID Type: DER_ASN1_DN (9)       <--------- Expect  ID_REC822_ADDR
      Protocol ID : Unused
      Port: Unused
      Identificatoin Data: 0         <--------- Expect nut
        rdnSequence: 5 items:
          RDNSequence item: 1 item (id-at-countryName=US)
          RDNSequence item: 1 item (id-at-stateOrProvinceName=New Hampshire)
          RDNSequence item: 1 item (id-at-organizationName=IOL)
          RDNSequence item: 1 item (id-at-organizatoinUnitName=IPv6)
          RDNSequence item: 1 item (id-at-commonName=NUT)
    ...

Created attachment 1144528 [details]
pluto log file

Created attachment 1144530 [details]
pcap file

Can use wireshark to decrypt IKE_AUTH request in attached pcap file

Initiator's SPI: A0D615DA4CD8E77E
Responder's SPI: 0102030405060708
SK_ei: DEC3D4701456044EA1E14B33E7FA2DF22FA1487CF82E466C
SK_er: 42F8B006115B7DABDC3BF5033332072A103FAF341B5E45E2
Encription algorithm: 3EDS [RFC2451]
SK_ai: F747A5FC67BA91C58DFA3F5CA5B4D16BC2044ECC
SK_ar: 096874EE72FB21A1718E63CF46F6A2D829AC2F49
Integrity algorithm:  HMAC_SHA1_96[RFC2404]

If you use leftcert=XXXX you should use leftid=%fromcert

certificate authentication always uses type DER_ASN1_DN.

ID_REC822_ADDR might be used for raw RSA keys (public keys without certificates)

Can you explain what the test case is really testing?

(In reply to Paul Wouters from comment #7)
> If you use leftcert=XXXX you should use leftid=%fromcert
> 
> certificate authentication always uses type DER_ASN1_DN.
> 
> ID_REC822_ADDR might be used for raw RSA keys (public keys without
> certificates)
> 
> Can you explain what the test case is really testing?

I am testing IKEv2 Conformance with 'UNH IOL' test suite.
Test case item is IKEv2.En.I.1.1.10.1(C). You can see the more detail info on this test item via https://www.ipv6ready.org/docs/Phase2_IKEv2_Conformance_Latest.pdf

I will try it as you said. Will close this bug if it can passes testing

still need more info on this

Hi Paul, here is the detail info of this test case:
Link:
IKEv2.EN.I.1.1.10.1 Part C, page 168, https://www.ipv6ready.org/docs/Phase2_IKEv2_Conformance_Latest.pdf

NUT - Node Under Test
TN  - Test Node

Purpose: 
    To verify an IKEv2 device handles CERTREQ payload and transmits CERT payload properly

References: 
    [RFC 4306] - Sections 1.2 and 3.8

Procedure:

   NUT             TN1  
    |             | 
    |------------>| IKE_SA_INIT request (HDR, SAi1, KEi, Ni) 
    |             | (Judgment #1) 
    |<------------| IKE_SA_INIT response (HDR, SAr1, KEr, Nr, CERTREQ) 
    |             | (Packet #1) 
    |             | 
    |------------>| IKE_AUTH request (HDR, SK {IDi, CERT, AUT
H, N, SAi2, TSi, TSr}) 
    |             | (Judgment #2) 
    |             | 
    V             V 
N: USE_TRANSPORT_MODE  

Expected Result:
Judgment #1 
The NUT transmits an IKE_SA_INIT request including "ENCR_3DES", "PRF_HMAC_SHA1", "AUTH_HMAC_SHA1_96" and "D-H Group 2" as proposed 
algorithms. 

Judgment #2 
The NUT transmits an IKE_AUTH request. The request includes an ID payload with 
ID_RFC822_ADDR and a CERT payload which contains 4 (X.509 Certificate - Signature) as Certificate Encoding and the NUT’s certificate as Certificate Data. 

Actual Result:
As said in Comment 3:

We failed at Judgment #2, the IKE_AUTH request should include an ID payload with ID_RFC822_ADDR(3), but include DER_ASN1_DN (9)

And as you said in comment 7, certificate authentication always uses type DER_ASN1_DN.

By the way, this test case can pass on RHEL-7.2 with libreswan 3.12-10.1.el7_1

It would help if you let others see all comments - I can't really judge about this because you keep your comments private.

This has been fixed in libreswan-3.21, which will be in rhel-7.5, and you can specify an email address provided it is a valid SAN on the certificate. I've moved this bug to that version for QA.

This issue will not be fixed for rhel6.

fix came in via rebase

upstream testcase https://github.com/libreswan/libreswan/tree/master/testing/pluto/ikev2-x509-09-san-email-match

OLD (libreswan-3.20-5.el7_4)
============================
SERVER
------
:: [   FAIL   ] :: File '/var/log/pluto/pluto.log' should contain 'IKEv2 mode peer ID is ID_USER_FQDN: 'client'' 
:: [   FAIL   ] :: File '/var/log/pluto/pluto.log' should contain 'ID type: ID_USER_FQDN (0x3)' 

CLIENT
------
:: [   PASS   ] :: File '/var/log/pluto/pluto.log' should contain 'IKEv2 mode peer ID is ID_USER_FQDN: 'server'' 
:: [   FAIL   ] :: File '/var/log/pluto/pluto.log' should contain 'ID type: ID_USER_FQDN (0x3)'

NEW (libreswan-3.23-0.1.rc4.el7)
================================
SERVER
------
:: [   PASS   ] :: File '/var/log/pluto/pluto.log' should contain 'IKEv2 mode peer ID is ID_USER_FQDN: 'client'' 
:: [   PASS   ] :: File '/var/log/pluto/pluto.log' should contain 'ID type: ID_USER_FQDN (0x3)' 

CLIENT
------
:: [   PASS   ] :: File '/var/log/pluto/pluto.log' should contain 'IKEv2 mode peer ID is ID_USER_FQDN: 'server'' 
:: [   PASS   ] :: File '/var/log/pluto/pluto.log' should contain 'ID type: ID_USER_FQDN (0x3)' 

See TJ#2258272 and TJ#2258274 for more details.

*** Bug 1375406 has been marked as a duplicate of this bug. ***

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0932