Ticket #195 (Fixed)Wed Dec 03 12:50:27 UTC 2008
SSL certificate expired
| Reported by: | Theo Markettos (89) | Severity: | Enhancement |
| Part: | Legacy: LigHTTPd (old web server configuration) | Release: | |
| Milestone: | Status | Fixed |
Details by Theo Markettos (89):
The SSL cert for www.riscosopen.org expired on 1st December.
Also it seems to be serving the www.riscosopen.org cert for www.riscosopen.co.uk (making this new ticket in the bug tracker put me on .co.uk). If you don’t want to buy two certs, perhaps you can standardise on only one domain for actually serving pages, and the rest redirects?
Changelog:
Modified by Andrew Hodgkinson (6) Wed, December 03 2008 - 16:36:45 GMT
- Severity changed from Major to Enhancement
We noticed this today ourselves. The Comodo e-mail messages were saying a 12th December expiry, which is what I expected based on the previous renewal. When originally renewed Comodo based the expiry on the renewal date, not the old expiry date plus one year, so we lost a couple of weeks; I complained and they reissued the certificate, but evidently, they didn’t reissue one with a new expiry date!
I’ve already bought a new certificate, this time from GoDaddy; silly name, but SSL certificates seem to be much the same from company to company and GoDaddy were much cheaper than Comodo.
UCC certificates to cover all of our domains are very much more expensive (a little over £100/year, roughly, versus about £18/year) so we don’t bother buying them. Automatic redirection to www.riscosopen.org from any other domain is a good idea and I’ll look into adding it to the server configuration. To keep track of this, I’ll leave the fault open but change its severity to “enhancement”.
Modified by Andrew Hodgkinson (6) Wed, December 03 2008 - 19:56:28 GMT
- Status changed from Open to Fixed
Redirection implemented. For SSL, the redirection happens too late; if a browser tries to connect via HTTPS on a different domain, then the user will already have been warned about the mismatch, if their browser implements such things. Should they proceed, though, the user will be redirected to a corrected HTTPS domain which means that subsequent bookmarks etc. would all be correct.
For insecure HTTP connections, the redirection is far more useful and should eliminate security warnings for users coming in via other domains if they subsequently try to log in via Hub.
Thanks for the suggestion.
