[Swan] OSX - SAN not matched, but debug shows a match

[Computerisms Corporation]

k, so I did have an epiphany; didn't help me solve the problem, but I 
had one.  Occurs I never checked the debug logs:

Mar 26 22:55:53 doorlian pluto[22028]: | required RSA CA is 'C=CA, 
ST=Yukon, O=Carcross//Tagish First Nations, OU=IT, CN=CTFN Certificate 
Authority'
Mar 26 22:55:53 doorlian pluto[22028]: | checking RSA keyid 
'@gatelian.computerisms.ca' for match with '@firewall.ctfn.ca'
Mar 26 22:55:53 doorlian pluto[22028]: | checking RSA keyid 'C=CA, 
ST=Yukon, O=Carcross//Tagish First Nations, OU=IT, CN=Ryan' for match 
with '@firewall.ctfn.ca'
Mar 26 22:55:53 doorlian pluto[22028]: | checking RSA keyid 
'ryan at ctfn.ca' for match with '@firewall.ctfn.ca'

^^This is the cert on the mac


Mar 26 22:55:53 doorlian pluto[22028]: | checking RSA keyid 
'@firewall.ctfn.ca' for match with '@firewall.ctfn.ca'

^^Looks like a match to me???


Mar 26 22:55:53 doorlian pluto[22028]: | trusted_ca_nss: trustee A = 
'C=CA, ST=Yukon, O=Carcross//Tagish First Nations, OU=IT, CN=CTFN 
Certificate Authority'
Mar 26 22:55:53 doorlian pluto[22028]: | trusted_ca_nss: trustor B = 
'C=CA, ST=Yukon, O=Carcross//Tagish First Nations, OU=IT, CN=CTFN 
Certificate Authority'
Mar 26 22:55:53 doorlian pluto[22028]: | key issuer CA is 'C=CA, 
ST=Yukon, O=Carcross//Tagish First Nations, OU=IT, CN=CTFN Certificate 
Authority'
Mar 26 22:55:53 doorlian pluto[22028]: |       #10 spent 1.21 
milliseconds in try_all_RSA_keys() trying a pubkey


 From here it checks the other certs in the NSS database for a few 
lines, and then it gives this:

Mar 26 22:55:53 doorlian pluto[22028]: "rw-ikev2"[1] 205.234.49.246 #10: 
Signature check (on @firewall.ctfn.ca) failed (wrong key?); tried *AwEAAggUh
Mar 26 22:55:53 doorlian pluto[22028]: | public key for 
@firewall.ctfn.ca failed: decrypted SIG payload into a malformed ECB 
(3NSS error: Not able to decrypt)
Mar 26 22:55:53 doorlian pluto[22028]: |     #10 spent 1.52 milliseconds 
in ikev2_verify_rsa_hash()

So how can it be successfully decrypting the key when Windows connects, 
but not when OSX connects?

ipsec auto --listall shows firewall.ctfn.ca as a public key and an x.509 
cert with a private key.






On 2020-03-26 10:51 p.m., Computerisms Corporation wrote:
> Hi Gurus,
> 
> I have been spinning my wheels on all day, maybe by sending this to the 
> list I will get an epiphany, or if not hopefully someone has some input.
> 
> have a firewall running v3.29, windows clients are connecting fine, 
> generated mobileconfigs are installing on the OSX clients and appear to 
> have all the correct details.  But when I connect with OSX (tested on 
> multiple machines using multiple mobileconfigs), the logs tell me the 
> cert has no matching SAN:
> 
> 
> Mar 26 21:25:50 doorlian pluto[16012]: "rw-ikev2"[6] 205.234.49.246 
> #720: No matching subjectAltName found for 'firewall.ctfn.ca'
> Mar 26 21:25:50 doorlian pluto[16012]: "rw-ikev2"[6] 205.234.49.246 
> #720: certificate does not contain subjectAltName=firewall.ctfn.ca
> Mar 26 21:25:50 doorlian pluto[16012]: "rw-ikev2"[6] 205.234.49.246 
> #720: Peer public key SubjectAltName does not match peer ID for this 
> connection
> Mar 26 21:25:50 doorlian pluto[16012]: "rw-ikev2"[6] 205.234.49.246 
> #720: IKEv2 mode peer ID is ID_FQDN: '@firewall.ctfn.ca'
> Mar 26 21:25:50 doorlian pluto[16012]: "rw-ikev2"[6] 205.234.49.246 
> #720: Signature check (on @firewall.ctfn.ca) failed (wrong key?); tried 
> *AwEAAbtUh
> Mar 26 21:25:50 doorlian pluto[16012]: "rw-ikev2"[6] 205.234.49.246 
> #720: RSA authentication of I2 Auth Payload failed
> Mar 26 21:25:50 doorlian pluto[16012]: "rw-ikev2"[6] 205.234.49.246 
> #720: responding to IKE_AUTH message (ID 1) from 205.234.49.246:4500 
> with encrypted notification AUTHENTICATION_FAILED
> Mar 26 21:25:50 doorlian pluto[16012]: "rw-ikev2"[6] 205.234.49.246 
> #720: deleting state (STATE_PARENT_R1) aged 0.171s and NOT sending 
> notification
> 
> I am not really clear which cert it is talking about, I would expect it 
> to be logging info about the cert on OSX, but the cert name is 
> appropriate for the firewall, and it does have a matching SAN:
> 
> certutil -L -n firewall.ctfn.ca -d sql:/etc/ipsec.d
> <snip>
>              Name: Certificate Subject Alt Name
>              DNS name: "firewall.ctfn.ca"
> 
>              Name: Certificate Key Usage
>              Usages: Digital Signature
>                      Non-Repudiation
>                      Key Encipherment
> 
>              Name: Extended Key Usage
>                  TLS Web Server Authentication Certificate
> </snip>
> 
> and I am reasonably certain I am using the correct settings in the conn:
> <snip>
>     left=firewall.ctfn.ca
>     leftsubnet=0.0.0.0/0
>     leftcert=firewall.ctfn.ca
>     leftid=@firewall.ctfn.ca
>     leftrsasigkey=%cert
>     leftsendcert=always
>     right=%any
>     rightca=%same
>     rightrsasigkey=%cert
>     rightid=%fromcert
> </snip>
> 
> On another firewall also running 3.29, I have OSX and windows clients 
> connecting fine; I have carefully compared all the configs and 
> certificates and the details seem to be consistent.  Clearly I have 
> overlooked something, wondering if anyone has an idea what it is?
> 
>