Home/ Questions/Q 7217885
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T21:24:37+00:00

When a user logs in to my website, I redirect him to a https://

  • 0

When a user logs in to my website, I redirect him to a https:// URL. (https://www.gruppenunterkuenfte.de/anbieter-bereich.html?next=/#einloggen)

If the user has set a wrong date on his machine (one year in the past), the certificate is considered invalid, for it is issued with a start of January 3rd 2012.

With this invalid certificate Safari and Chrome then seam to block scripts that load from external sources. (For example: https://ajax.googleapis.com/ajax/libs/jquery/1.5.2/jquery.min.js), which causes the login to not function.

Now my question is, what would be a good solution to this problem?

  1. Send the servers date in the JS-code and compare it with JS to the users current time. If it differs more than 24h, show the user a warning to set his date correctly. But that could be annoying for users… And maybe they don’t have privileges to change it.
  2. Don’t load JS files from external domains. Then the certificate would still be invalid, but the page would function. However I prefer loading the scripts from ajax.googleapis.com for performance reasons.
  3. Would it be possible to get a certificate, that is valid with whatever date the user has set?
  4. Any other solutions I did not think of?
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I suppose you could do #1 (pre-HTTPS) if you really wanted to, but as dirkbonhomme indicates, it’s probably not worth the effort.

    As for the rest…. DON’T DO THEM!

    For #2, if they load a page with an invalid certificate, all bets are off for security. Why bother with encryption at all? Plus you are training your users to just click through security warnings, which degrades overall Internet security. People are already way too willing to blindly accept what pop-up windows tell them. This behavior then facilitates security compromises, malware distribution, etc.

    For #3, no, not as far as I know. And you wouldn’t want this. The notion of an expiring certificate is important to the integrity of the certificate signing system. Since most people don’t update their CRLs (and, inexplicably, most browsers don’t seem to do this automatically), checking cert expiration is the last line of defense against certificates that might have been stolen or otherwise compromised. It puts an upper bound on how long such certs can remain active in the wild.

    For #4… the correct solution is for the user to fix their broken machine. A great many schemes depend on accurate time, and the user should know that things will break if the time isn’t updated properly. If this is a recurring problem for your user base, maybe introduce them to a little something called NTP.

    • 0