How to properly use serverCertificateIssuerCommonName?

I've written a configuration profile to manage IKEv2 VPN, everything works except that serverCertificateIssuerCommonName doesn't seem to work as expected.



The reference says this key is required if if the CertificateType key is included, and it causes IKEv2 to send the certificate request.



My server is using certificates issued from let's encrypt. I tried setting serverCertificateIssuerCommonName to either DST Root CA X3, which is CA's CN, or Let's Encrypt Authority X3, which is intermediate certificate's CN. Neither cause IKEv2 to send to certficate request. In both cases, IKEv2 complains something like



ikev2_crypto_copy_remote_certi:1727 BACKTRACE failed to retrieve remote CA cert data by CN (DST Root CA X3))



It only works if I manually add server's issued certificate to Keychain, and specify Let's Encrypt Authority X3 as serverCertificateIssuerCommonName, but that defeats the purpose of using a publicly trusted certficate.



I wonder what's the correct way of specifying serverCertificateIssuerCommonName without importing any certficates?



IKEv2 rfc says the certificate request should contain SHA-1 hashes of the public keys of trusted Certification Authorities. So I expect DST Root CA X3 to work here.



What did I miss?



Thanks.

Replies

I did more testing and can confirm that if I manually import DST Root CA X3's certificate to my login keychain, IKEv2 can connect.


That means serverCertificateIssuerCommonName ignores the system keychain when looking for a certificate.


But does that mean NEVPNManager encourage us to first ask users to import (and trust) a CA certificate into user's keychain, so it can accept the certificate from my server? I don't think cocoa has an API for that? And if I'm not wrong, ask users to trust a CA is actually frown upon?


What options do I have if I want to use certificate based IKEv2 in NEVPNManager?

hi hgl,


did you find a way to programmaticly install the root cert?