I have 19 websites (example: bellagreyhound.com) covered by a certificate which is set to auto-renew every month. This process appears to be working, I do not see any “red flags” in the log file.
Something is not right, however, when any of the websites are viewed in Safari on any Apple IOS device. Safari on a PC is fine, as is Chrome on the same IOS devices and on a PC.
The problem appears to only present itself around the renewal date. I saw it in the 2 days before and 1 after June 30 (or so).
Safari sees the certificate and reports it valid, but out of date. For example, on June 29 Safari reported the certificate as valid between the dates of June 30 and September 30. Safari plasters the web client’s screen with a Unsafe Website message.
Anyone have any idea how I might proceed to prevent this highly obnoxious behavior?
Thanks and best regards, jb
----- Info -----
The CertifyTheWeb certificate manager version is 4.1.6.0, which “check for updates” tells me is the latest version.
It is running on an Amazon EC3 server running Windows server 2016 v1607.
To me, it sounds like Safari on iOS has trouble with knowing the correct time. Maybe it thinks it is in the wrong timezone?
Looking at some of my own certificates from Let’s Encrypt… the “Valid from” field for the certificate is set to one-hour before the certificate was generated. Meaning only systems that are “time traveling” would think that it is invalid.
There’s an old sysadmin adage that says time travel is dangerous. In this context, it means setting a computer’s time to something that it is not. The moment you do so, you risk breaking things immediately and it makes it hard to correlate things.
I feel like the Let’s Encrypt servers will set the times correctly on their end, so it doesn’t matter what timezone your server thinks it is in. I would look at the iOS device itself or see if it’s a known issue for Safari on that platform. (issues knowing the correct time)
I much appreciate the suggestion. However I doubt that time travel/accuracy was the problem. As of now, my server time is within 2 seconds of time.gov. Just before the end of June 2019 I verified the Safari problem as existing on three separate IOS devices. As of right now, all three devices are also within 2 seconds of time.gov.
The problem only asserted itself on Safari on these IOS devices. Chrome on the same devices did not show any problem. My web customer’s client (on an unknown device) also exhibited the problem.
What I did notice was that the certificate showed a valid range beginning in the future (ie, on June 29 it was valid between June 30 and Sept 30. Apparently only Safari on IOS paid any attention to this.
I will be watching it closely (with bow and poisoned arrows) as the end of this month (July 2019) approaches.
My concern is that Safari makes such a rude matter of it.
I honestly doubt Let’s Encrypt will ever provide a certificate for the future regardless of what information your server gives it. I still think it is a timezone problem on the client that is examining the certificate… where it believes it is in a different timezone and misinterprets the UTC time on the certificate.
The problem being on the server end makes no sense. Having servers send HTTP headers with false date headers and having the client believe it for the purposes of certificate validation is a huge security hole. Having the ability to request certificates from the future via Let’s Encrypt invalidates the idea of short-lived certificate security.
As I said before, my computer with the correct time and timezone always determines that the certificate is valid for 60 minutes before it is actually issued. But if my computer thought that it was in the PDT timezone but with the local EDT time set… the certificate would appear to be not-valid for two hours after issuance. (or maybe the opposite direction, but the general idea stands)
New month and I unearthed the problem leading to the “safety” bug! Turns out it had (embarrassingly) nothing to do with IOS, nor safari. It was repeatable on Chrome under IOS and Chrome under Windows on a PC. The problem turned out to be that pesky subdomain www.bellagreyhound.com (as opposed to the root domain, bellagreyhound.com). The certificate I had gotten only covered the root domain. Now all is ok with a certificate explicitly covering both. You can still see the failure by looking at (say) foo.xxx, or foobar.xxx … but ha ha, who cares about that? In theory they will allow a wildcard spec such as *.xxx, but that requires the more involved dns validation instead of the easier http validation.
Hmm, that is a common problem, probably. I remember having to do that myself because even with rewrite rules to redirect WWW to non-WWW, browsers would check the certificate against the WWW before the redirect and it would display the warning. WWW subdomains seem like artifacts of the past, but people still think about them and they get enabled by default a lot.