mirror of
https://github.com/FiloSottile/mkcert.git
synced 2026-04-25 13:36:02 +03:00
[GH-ISSUE #206] Wildcard certificates on Safari, macOS Catalina #134
Labels
No labels
TLS stack issue
Windows
bug
duplicate
duplicate
enhancement
help wanted
help wanted
pull-request
question
question
root store
waiting for info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mkcert#134
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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)
@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.
@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:
I also tried emptying Safari cache and a restart, all without success. If you have some other advice I would really appreciate any help.
@anmartini commented on GitHub (Oct 11, 2019):
Ok, it appears to be a problem with
.testdomains.I tried with a
.localdomain and subdomain and it works fine. Is it possible that with Catalina Apple limited.testdomains?@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?
@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.
@ruimarinho commented on GitHub (Nov 12, 2019):
I am also experiencing the same issue with a wildcard
.testdomain on macOS Catalina running v1.4.1.@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:
I can also confirm that it is a Catalina thing... 10.14 does not have this problem AFAIK.
@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!
@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.
@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.
@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!
@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.
@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. 😞