Certificate Name does not match input

Was fighting the same issue myself. Had so many clues but it wasn't until I found out that Apple has new requirements for trusting certificates in macOS 10.15 Catalina and iOS 13 that got the issue resolved once I met ALL the requirements.

In my case, my firewall was giving the "certificate name does not match input error", but my Synology NAS certificate had no issues, nor did another product I use with my private CA's certs. Just like your screenshot, the name I was requesting matched the certificate.

My certificate was for the default length my CA interface populates which is 10 years−way longer than the 825 day limit Apple places on TLS server certificates now.

If the certificate in your screenshot was issued the day you posted this question (or earlier), then your certificate is valid for too many days(826+) and that may be your problem too.

I am having this exact issue with my work address. How do I fix it?

Thanks for the information. Can you explain how to fix it?

nickishafromjacksonville, from the Internet that certificate is working fine for me.

The certificate hasn't been updated since April 11, 2019 (nobody re-issued it recently), isn't valid for too long (13 months), includes the correct SAN records for the host name, and uses an appropriate SHA-256. I don't see any reason for it to fail and as my screen shot shows, its not failing for me. The certificate serial I see is 0E FB 2A 1D D9 C4 EF F2 92 CD F5 24 24 61 62 57.

Not sure what interface you are taking a screen shot of, but the OP included the address bar to prove the host name accessed matches the certificate because a misconfigured web/DNS server would also produce the same error (sending wrong cert for the host name accessed).

I also note that this interface doesn't show the CA path (relation of the certificate to its top level trusted issuer) like it does in Safari. Perhaps this specific computer has some manually added certificates in the Keychain creating conflicts?

Hiob86,

October 9, 2019 to Jan 12, 2022 is 826 days (not including Jan 12th).

https://www.timeanddate.com/date/durationresult.html?m1=10&d1=09&y1=2019&m2=01&d2=12&y2=2022

This exceeds the 825 day requirement.  If you'd just issue a shorter certificate (365 days for example) and it still had the problem, we can move on past the date issue.  As is, it seems like that is at least one of your problems.

You are correct that when the validity period is your only issue, you do get a different error.  I issued a test certificate exactly like the one that fixed my issue, but with a 10 year validity period, and it got the error "certificate is not standards compliant".

When I was comparing my internal certificates that had the issue and those that didn't, I did notice that Purpose #2 (see screenshot below) was missing on my broken certificate. That certificate was issued in 2015, so I assume my CA software updated the required minimal fields for TLS server certificates because the field is present on any certs I issue today. In terms of the article I shared and the listed requirements, I think IKE Intermediate under Extended Key Usage is the "TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID" requirement Apple mentioned.

But in the end, our problem is that the error message "certificate name does match input" does not reflect the actual problem with the certificate. I believe this is because when failing the new requirements, in code the trusted host name list is empty and null doesn't match our input. Kind of an error priority issue when you have (to the best of my knowledge) code that only surfaces a single error message (the most critical) in the Show Certificate screen of Safari.