[Users] [Bulk] Re: Certificate pop-up message
ma1l1ists at yahoo.co.uk
Thu Oct 4 21:38:11 CEST 2012
> On Thu, 4 Oct 2012 17:44:36 +0100
> Kevin Chadwick <ma1l1ists at yahoo.co.uk> wrote:
> > It certainly doesn't define that. In the case I have stated it is not
> > expired it is mistakenly thought to have gone past the intended
> > replacement date.
> From RFC 6101 (SSL v3.0):
> certificate_expired: A certificate has expired or is not currently
> "Expired" and "invalid" are synonymous in the SSL RFCs. The TLS RFCs
> have a copy-paste of this definition. You can read the relevant RFCs
> for yourself to see how expired certificates are supposed to be
It seems you can't differentiate between an actually expired
certificate and one the computer believes is expired! The RFC refers to
an actually expired certificate. Your barking up the wrong tree.
> > His clock does work it's just forgotten the time.
> A clock that never has the correct time is broken.
Talking definitions, there are no clocks with the "right time". Why are
you wasting our time. It has the right time until his laptop is
unplugged because his laptop battery is a dud too and costs another
fifty quid to replace.
> > Right, so you want him to pay fifty pounds to replace a battery in
> > a laptop worth a hundred pounds.
> This is the second funniest thing I've seen today. The first is
> Yahtzee's review of "Borderlands 2". Not only is your friend's computer
> broken but it's stupidly designed as well. The suggestion that the IETF
> and the Claws developers bend over to cater to it is absurd. It's not
> The suggestion that NTP is no guarantee is even more absurd. I've
> deployed and managed NTP in environments where milliseconds accuracy is
> required. This on x86 hardware which is notorious for wildly inaccurate
> real-time clocks. One of the nodes in one of my clusters had RTC drift
> exceeding an hour a day but NTP kept the system time accurate to within
> 1-2 milliseconds.
You assume again but I never said NTP is inaccurate. I said it is no
guarantee that clients have the correct time when needed (for lots of
reasons) and this should not be assumed and in fact almost never is
except incorrectly or in controlled specific scenarios or constantly
connected and powered systems.
> Today I manage about 30 Xen user domains, none of which rely on
> hardware clocks. They rely entirely on NTP and their kernel tickers for
> managing wall clock time. I haven't been paying close attention to
> their clocks because I only need sub-minute accuracy for my Kerberos
> realm. None of the nodes running NTP ever have time problems.
> My advice: Install NTP correctly on your friend's computer. And stop
> ranting because the Claws developers aren't going to change their minds
> about intentionally deploying broken behavior in the software they write
> and maintain.
Broken how? I'm not ranting at all, I simply commented on a common
assumption that isn't always correct and relevant at the moment for web.
Perhaps I should learn to keep strictly to mailing list relevence (mail)
but maybe that would be a bad thing too (future dev work and
NTP is enabled by default with Windows and Ubuntu, yet he has
problems on both.
He has a watch and a phone and a clock and there are websites hat get
the time from an atomic clock for free, what time problems do you think
He doesn't care that his computer has the wrong time he just wants to
know why his computer has been needlessly broken by the software. All
he cares about is linux dropping to a shell during boot (I think fixed
in Linux now, which shows it was wrong) and not being able to use the
web and email and perhaps in the future websites denying a legit user
access due to incorrect assumption by developers cripling software
needlessly (not meaning claws at all here but could possibly? be
improved). HSTS won't last long if data showing customers are lost
because of it comes along.
'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
More information about the Users