[GH-ISSUE #206] Wildcard certificates on Safari, macOS Catalina #134

Closed
opened 2026-02-25 22:32:41 +03:00 by kerem · 13 comments
Owner

Originally created by @anmartini on GitHub (Oct 10, 2019).
Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/206

On macOS Catalina I can not use wildcard certificates with Safari.

They work fine on Chrome and Firefox, but Safari (13.0.2 and Technology Preview) complains that "Certificate name does not match input".

I have the same problem with old and new certificates, with and without multiple names.
Certificates with multiple names work with the non-wildcard names (e.g. a certificate for "domain.test" and "*.domain.test" works fine with https://domain.test but fails with https://sub.domain.test)

wildcard

Originally created by @anmartini on GitHub (Oct 10, 2019). Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/206 On macOS Catalina I can not use wildcard certificates with Safari. They work fine on Chrome and Firefox, but Safari (13.0.2 and Technology Preview) complains that "Certificate name does not match input". I have the same problem with old and new certificates, with and without multiple names. Certificates with multiple names work with the non-wildcard names (e.g. a certificate for "domain.test" and "*.domain.test" works fine with https://domain.test but fails with https://sub.domain.test) ![wildcard](https://user-images.githubusercontent.com/2474517/66596385-136fd600-eb9d-11e9-93ae-7016a97e5633.png)
kerem closed this issue 2026-02-25 22:32:41 +03:00
Author
Owner

@rfay commented on GitHub (Oct 10, 2019):

I just tested on Catalina, Safari, and used a hostname that figured in a wildcard, and it seemed to work ok.

If you're not using mkcert v1.4, please do upgrade to it. I assume you must be using 1.4 or probably nothing would work.

Screenshot_10_10_19__1_02_PM Screenshot_10_10_19__1_02_PM
<!-- gh-comment-id:540732633 --> @rfay commented on GitHub (Oct 10, 2019): I just tested on Catalina, Safari, and used a hostname that figured in a wildcard, and it seemed to work ok. If you're not using mkcert v1.4, please do upgrade to it. I assume you must be using 1.4 or probably nothing would work. <img width="886" alt="Screenshot_10_10_19__1_02_PM" src="https://user-images.githubusercontent.com/112444/66598479-5ced0080-eb5e-11e9-97fe-e7dfe606fd9c.png"> <img width="472" alt="Screenshot_10_10_19__1_02_PM" src="https://user-images.githubusercontent.com/112444/66598501-66766880-eb5e-11e9-9d38-c103d9d0f32a.png">
Author
Owner

@anmartini commented on GitHub (Oct 11, 2019):

I really can't understand why Safari says the certificate is not valid.
This is the curl verbose output for a new certificate I made using mkcert 1.4.0:

➜  ~ curl -Iv https://sub.domain.test
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to sub.domain.test (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: O=mkcert development certificate; OU=anmartini@bitApp-MacMini-2 (Andrea Martini)
*  start date: Jun  1 00:00:00 2019 GMT
*  expire date: Oct 10 18:13:53 2029 GMT
*  subjectAltName: host "sub.domain.test" matched cert's "*.domain.test"
*  issuer: O=mkcert development CA; OU=anmartini@bitApp-MacMini-2; CN=mkcert anmartini@bitApp-MacMini-2
*  SSL certificate verify ok.
> HEAD / HTTP/1.1
> Host: sub.domain.test
> User-Agent: curl/7.64.1
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: nginx/1.17.3
Server: nginx/1.17.3
< Date: Fri, 11 Oct 2019 08:13:00 GMT
Date: Fri, 11 Oct 2019 08:13:00 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 400
Content-Length: 400
< Last-Modified: Fri, 19 Jul 2019 09:04:24 GMT
Last-Modified: Fri, 19 Jul 2019 09:04:24 GMT
< Connection: keep-alive
Connection: keep-alive
< ETag: "5d318798-190"
ETag: "5d318798-190"
< Accept-Ranges: bytes
Accept-Ranges: bytes

< 
* Connection #0 to host sub.domain.test left intact
* Closing connection 0

I also tried emptying Safari cache and a restart, all without success. If you have some other advice I would really appreciate any help.

<!-- gh-comment-id:540965144 --> @anmartini commented on GitHub (Oct 11, 2019): I really can't understand why Safari says the certificate is not valid. This is the curl verbose output for a new certificate I made using mkcert 1.4.0: ``` ➜ ~ curl -Iv https://sub.domain.test * Trying 127.0.0.1... * TCP_NODELAY set * Connected to sub.domain.test (127.0.0.1) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem CApath: none * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: O=mkcert development certificate; OU=anmartini@bitApp-MacMini-2 (Andrea Martini) * start date: Jun 1 00:00:00 2019 GMT * expire date: Oct 10 18:13:53 2029 GMT * subjectAltName: host "sub.domain.test" matched cert's "*.domain.test" * issuer: O=mkcert development CA; OU=anmartini@bitApp-MacMini-2; CN=mkcert anmartini@bitApp-MacMini-2 * SSL certificate verify ok. > HEAD / HTTP/1.1 > Host: sub.domain.test > User-Agent: curl/7.64.1 > Accept: */* > < HTTP/1.1 200 OK HTTP/1.1 200 OK < Server: nginx/1.17.3 Server: nginx/1.17.3 < Date: Fri, 11 Oct 2019 08:13:00 GMT Date: Fri, 11 Oct 2019 08:13:00 GMT < Content-Type: text/html Content-Type: text/html < Content-Length: 400 Content-Length: 400 < Last-Modified: Fri, 19 Jul 2019 09:04:24 GMT Last-Modified: Fri, 19 Jul 2019 09:04:24 GMT < Connection: keep-alive Connection: keep-alive < ETag: "5d318798-190" ETag: "5d318798-190" < Accept-Ranges: bytes Accept-Ranges: bytes < * Connection #0 to host sub.domain.test left intact * Closing connection 0 ``` I also tried emptying Safari cache and a restart, all without success. If you have some other advice I would really appreciate any help.
Author
Owner

@anmartini commented on GitHub (Oct 11, 2019):

Ok, it appears to be a problem with .test domains.
I tried with a .local domain and subdomain and it works fine. Is it possible that with Catalina Apple limited .test domains?

<!-- gh-comment-id:540970921 --> @anmartini commented on GitHub (Oct 11, 2019): Ok, it appears to be a problem with `.test` domains. I tried with a `.local` domain and subdomain and it works fine. Is it possible that with Catalina Apple limited `.test` domains?
Author
Owner

@rfay commented on GitHub (Oct 11, 2019):

Interesting. I know that a real CA could never issue a cert for a .test domain... so maybe they've written this into the browser?

<!-- gh-comment-id:541036819 --> @rfay commented on GitHub (Oct 11, 2019): Interesting. I know that a real CA could never issue a cert for a .test domain... so maybe they've written this into the browser?
Author
Owner

@anmartini commented on GitHub (Oct 11, 2019):

The strange thing is that with non-wildcard names it works with .test domains.
I also had problems with cookies, that weren't shared between sub domains when using .test.
I'll close the issue as this seems to me a problem with Safari, but maybe it could be useful to add a warning in mkcert.

<!-- gh-comment-id:541062964 --> @anmartini commented on GitHub (Oct 11, 2019): The strange thing is that with non-wildcard names it works with .test domains. I also had problems with cookies, that weren't shared between sub domains when using .test. I'll close the issue as this seems to me a problem with Safari, but maybe it could be useful to add a warning in mkcert.
Author
Owner

@ruimarinho commented on GitHub (Nov 12, 2019):

I am also experiencing the same issue with a wildcard .test domain on macOS Catalina running v1.4.1.

<!-- gh-comment-id:552965634 --> @ruimarinho commented on GitHub (Nov 12, 2019): I am also experiencing the same issue with a wildcard `.test` domain on macOS Catalina running v1.4.1.
Author
Owner

@kamui545 commented on GitHub (Apr 24, 2020):

I've got the same issue and I believe it is due to ATS (App Transport Security), both Safari and iOS Simulator cannot connect to my API.

You can check like this:

nscurl --ats-diagnostics https://domain.test # pass
nscurl --ats-diagnostics https://subdomain.domain.test # fail

I can also confirm that it is a Catalina thing... 10.14 does not have this problem AFAIK.

<!-- gh-comment-id:619055876 --> @kamui545 commented on GitHub (Apr 24, 2020): I've got the same issue and I believe it is due to ATS ([App Transport Security](https://developer.apple.com/security/)), both Safari and iOS Simulator cannot connect to my API. You can check like this: ```bash nscurl --ats-diagnostics https://domain.test # pass nscurl --ats-diagnostics https://subdomain.domain.test # fail ``` I can also confirm that it is a Catalina thing... 10.14 does not have this problem AFAIK.
Author
Owner

@landabaso commented on GitHub (May 26, 2020):

Thanks so much @anmartini @ruimarinho @kamui545 for sharing your findings with .test domains, cookies, subdomains & Safari.

I've spent a couple of days banging my head trying to understand why I could share subdomain cookies on my production .com server but not on my .test development server.

In fact I opened this thread on SO because I felt hopeless:
https://stackoverflow.com/questions/62023857/sharing-cookies-across-test-sub-domains-in-safari-13-not-possible

So, what would you guys recommend? Not using .test but using .local? What about .localhost? Any other random extension?

From what you said, it looks like .test is somehow hardcoded into Safari. Did you find any way to make it possible to use .test extension after your original posts?

Thanks!

<!-- gh-comment-id:634207380 --> @landabaso commented on GitHub (May 26, 2020): Thanks so much @anmartini @ruimarinho @kamui545 for sharing your findings with .test domains, cookies, subdomains & Safari. I've spent a couple of days banging my head trying to understand why I could share subdomain cookies on my production .com server but not on my .test development server. In fact I opened this thread on SO because I felt hopeless: https://stackoverflow.com/questions/62023857/sharing-cookies-across-test-sub-domains-in-safari-13-not-possible So, what would you guys recommend? Not using .test but using .local? What about .localhost? Any other random extension? From what you said, it looks like .test is somehow hardcoded into Safari. Did you find any way to make it possible to use .test extension after your original posts? Thanks!
Author
Owner

@anmartini commented on GitHub (May 27, 2020):

Hey,
I didn't find any solution other than changing the domain from .test to .local.
In other projects I used a "regular" public domain, putting it in /etc/hosts file and creating a certificate with mkcert. This is probably the method that gave me less problems with cookies and cors issues.

<!-- gh-comment-id:634867882 --> @anmartini commented on GitHub (May 27, 2020): Hey, I didn't find any solution other than changing the domain from .test to .local. In other projects I used a "regular" public domain, putting it in /etc/hosts file and creating a certificate with mkcert. This is probably the method that gave me less problems with cookies and cors issues.
Author
Owner

@landabaso commented on GitHub (Jun 2, 2020):

Thanks @anmartini. I switched to .local and cookies work again. ".test" domains bring these problems. Also wildcard domain certificates were not working for ".test". They should really be avoided on MacOs.

<!-- gh-comment-id:637394291 --> @landabaso commented on GitHub (Jun 2, 2020): Thanks @anmartini. I switched to .local and cookies work again. ".test" domains bring these problems. Also wildcard domain certificates were not working for ".test". They should really be avoided on MacOs.
Author
Owner

@Kichikahunov commented on GitHub (Jun 19, 2020):

Thanks! I had the same problems with cookies and certs, after switching from test to local everything works again!

<!-- gh-comment-id:646562490 --> @Kichikahunov commented on GitHub (Jun 19, 2020): Thanks! I had the same problems with cookies and certs, after switching from test to local everything works again!
Author
Owner

@landabaso commented on GitHub (Sep 3, 2020):

Safari is a nightmare. Is anyone now also having CORS issues with .local domains (calling a subdomain is blocked) in Safari? I think something changed again.

<!-- gh-comment-id:686302151 --> @landabaso commented on GitHub (Sep 3, 2020): Safari is a nightmare. Is anyone now also having CORS issues with .local domains (calling a subdomain is blocked) in Safari? I think something changed again.
Author
Owner

@anmartini commented on GitHub (Sep 3, 2020):

I had problems with CORS and cookies even with .local, I've now switched to "fake" but regular TLDs, like .work, .dev.
It really is a nightmare. 😞

<!-- gh-comment-id:686341169 --> @anmartini commented on GitHub (Sep 3, 2020): I had problems with CORS and cookies even with .local, I've now switched to "fake" but regular TLDs, like .work, .dev. It really is a nightmare. 😞
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/mkcert#134
No description provided.