-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generate HTTPS certificates accepted by iOS 13 / macOS Catalina #6036
Comments
I installed Syncthing on two Macs, one running Mojave and the other running Catalina. When trying to access the web GUI using https, it warns of the invalid certificate, but, after dismissing that dialog and entering my password, it works. This is the same on both machines. Syncing works perfectly and without a warning, I have only tested it within my LAN though. |
That warning (self signed cert), cannot be avoided. |
Yes, but this issue talks about a potential new problem (certificates valid for too long), which does not apply for syncthing - no change in behavior for macOS 10.15, since the cert was untrusted anyway. As formulated by calmh: "The "fuck it, I trust this cert anyway" dialog for self-signed certs does override this requirement too.". The issue can be closed from my point of view. |
That's not my interpretation at all. I upgraded yesterday and a newly generated Syncthing certificate shows this now in Safari: Note "revoked" status and complete lack of "visit this website anyway". A certificate with shorter lifetime works as expected. Note that none of this applies to certificates created before June or July or something, so it's likely you're looking at an older certificate. |
This adds a certificate lifetime parameter to our certificate generation and hard codes it to twenty years in some uninteresting places. In the main binary there are a couple of constants but it results in twenty years for the device certificate and 820 days for the HTTPS one. 820 is less than the 825 maximum Apple allows nowadays. This also means we must be prepared for certificates to expire, so I add some handling for that and generate a new certificate when needed. For our own certificates (common name Syncthing) we regenerate a month ahead of time. For other certificates we leave well enough alone.
That's interesting! I messed up the testing in that I though I was testing with Safari as that's the most Mac:y browser, but Syncthing opened the page in my default browser (Edge) and I just rolled with it. In Safari I see the same as you and @GermanCoding - it works fine when force-accepted. In Edge I see the more aggressive behavior - the long certificate is not possible to accept as it's considered "revoked". In Chrome (on which Edge is based) I see the same thing: "revoked" and no option to continue: Summing up I conclude the problem remains, but not in Safari specifically. |
Maybe this is not intentional from the Chrome/Edge side and just a side effect of the CERT_ERR_REVOKED rather than CERT_ERR_INVALID_AUTHORITY from the backend. |
This adds a certificate lifetime parameter to our certificate generation and hard codes it to twenty years in some uninteresting places. In the main binary there are a couple of constants but it results in twenty years for the device certificate and 820 days for the HTTPS one. 820 is less than the 825 maximum Apple allows nowadays. This also means we must be prepared for certificates to expire, so I add some handling for that and generate a new certificate when needed. For self signed certificates we regenerate a month ahead of time. For other certificates we leave well enough alone.
Some new requirements have been added in new OSes. One thing we will run afoul of:
We generate GUI certs with very long validity time. We'd need to cut this down to two years, and then also be prepared to re-generate the cert before it expires.
(I haven't yet tested whether the "fuck it, I trust this cert anyway" dialog for self-signed certs maybe overrides this requirement too.)
The text was updated successfully, but these errors were encountered: