4.3 Configuring the peer side using CA certificates
http://www.strongswan.org/docs/readme4.htm#section_4.3
The ID by which a peer is identifying itself during IKE main mode can by any of the ID types IPV4_ADDR, FQDN, USER_FQDN or DER_ASN1_DN. If one of the first three ID types is used, then the accompanying X.509 certificate of the peer must contain a matching subjectAltName field of the type ipAddress (IP:), dnsName (DNS:) or rfc822Name (email:), respectively. With the fourth type DER_ASN1_DN, the identifier must completely match the subject field of the peer's certificate. One of the two possible representations of a Distinguished Name (DN) is the LDAP-type formatRe: [strongSwan] rightid (Ipsec with Certificates)
rightid="C=CH,O=Linux strongSwan, CN=sun.strongswan.org"Additional whitespace can be added everywhere as desired since it will be automatically eliminated by the X.509 parser. An exception is the single whitespace between individual words , like e.g. in Linux strongSwan, which is preserved by the parser.
The Relative Distinguished Names (RDNs) can alternatively be separated by a slash ( '/') instead of a comma (',')
This is the representation extracted from the certificate by the OpenSSL command line optionrightid="/C=CH/O=Linux strongSwan/CN=sun.strongswan.org"
openssl x509 -in sunCert.pem -noout -subject
https://www.mail-archive.com/users@lists.strongswan.org/msg04084.html
Re: [strongSwan] understanding %fromcertrightid and leftid are required to prevent an endpoint having a valid and trusted certificate to take on the identity of another endpoint (e.g. a client acting as the SEGW).The leftid must exactly match either the subjectDistinguishedName or a subjectAltName in the leftcert. rightid must match the identity of the remote endpoint but may contain wildcards, the most general being rightid=%any which returns a full match for any id. rightid is sent by the initiator in the optional IDr payload in order to assist the remote endpoint in the selection of the identity to be used if the remote endpoint has multiple identities (e.g. multiple certificates). If rightid contains at least one wildcard ('*' character) then IDr is omitted but the the responder must always return its full IDr not containing any wildcards. In your first example where you define rightid="C=*, O=*, OU=*, CN=*" the IDr payload is not sent by the initiator and the responder returns an IDr of the form "O=Alcatel, CN=654...@alcatel-lucent.com" which does not match your rightid template because the C= and OU= RDNs are missing and the following local error is produced: constraint check failed: identity 'C=*, O=*, OU=*, CN=*' required selected peer config '30' inacceptable no alternative config found In order for your example to work you must either define rightid="O=*, CN=*" or if you don't know exaclty which type of RDNs are used by the SEGW in its certificate just rightid=%any Please be aware that the use of wildcards makes your endpoints vulnerable to kind of man-in-the-middle attacks mentioned in the first paragraph. In your second example you didn't specify any rightid. In that case by default the IP address specified by right is used as rightid, i.e. rightid=172.21.11.181 Since this IDr is not contained in the SEGW's certificate the remote error parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ] received AUTHENTICATION_FAILED notify error is received.
https://www.mail-archive.com/users@lists.strongswan.org/msg06371.html
'Re: [strongSwan] FQDN based certificate authentication for ikev2' - MARCleftid=%fromcertis an OpenSwan option not supported by strongSwan. The strongSwan configuration is leftcert=carolCert.pem leftid=ca...@strongswan.org or simply leftcert=carolCert.pem If leftid is missing then left, i.e. the IP address is chosen by default for leftid but since the IP address usually is not contained as a subjectAltName in the certificate, the fallback is for leftid to assume the value of the subject Distinguished Name as e.g. leftid="C=CH, O=strongSwan, CN=ca...@strongswan.org"
https://www.assembla.com/spaces/wbgi-tpe
'Re: [strongSwan] Cannot set ID to FQDN with certificate loaded,' - MARCif you want to use FQDNs as IDs then you must set rightid and leftid accordingly: On the initiator 10.0.0.2: left=10.0.0.2 leftcert="/etc/ipsec/certs/ipsec.d//certs/ib-cert.pem" leftid=ib.atca.nsn.com right=10.0.0.1 rightid=cla.atca.nsn.com On the responder 10.0.0.1: left=10.0.0.1 leftcert="/etc/ipsec/certs/ipsec.d//certs/cla-cert.pem" leftid=cla.atca.nsn.com right=%any
http://marc.info/?l=strongswan-users&m=121804213112206
QA Cafe - Knowledgebase - How do I display the contents of a SSL certificate?subjectAltNames don't go into the Distinguished Name (DN) itself as you did in [O=MyCo Ltd, OU=SW, L=Swindon, ST=Wiltshire, C=GB, CN=sgw.myco.com, subjectAltName=sgw.myco.co] but into an X.509v3 certificate extension. Enter the subjectAltName in the form subjectAltName=DNS:sgw.myco.com in the appropriate place in your openssl.cnf file before you generate your certificate.
https://lounge.qacafe.com/kb/articles/show/153
# openssl x509 -in acs.qacafe.com.pem -text