- marked as enhancement
- marked as
- removed comment
Einstein toolkit sites with invalid security certificates
Issue #1207
closed
https://einsteintoolkit.org exists but has an invalid security certificate (http://www.sslshopper.com/ssl-checker.html#hostname=einsteintoolkit.org). I don't think we need SSL/TLS on this server. It should either be disabled or a valid certificate used.
The same applies to https://cactuscode.org (http://www.sslshopper.com/ssl-checker.html#hostname=cactuscode.org).
Note that Frank's page (http://www.cct.lsu.edu/~knarf/cgi-bin/monitor.cgi) reports these certificates as self-signed; they are also expired. Self-signed certificates on public websites are bad: they encourage people to click through the warnings.
Keyword:
Comments (7)
-
-
- removed comment
Is this still an issue?
-
- removed comment
https://einsteintoolkit.org/ is fine, and has been for some time. Other domains we own don't have certificates attached, and it is not sure whether we actually go all the way to get them, e.g. git.einsteintoolkit.org.
I'll keep the ticket open since we should fix https://cactuscode.org/, which at the moment only serves a test page, not the same as http://cactuscode.org/
-
- removed comment
I think the issue was occasionally not that the certificate itself was invalid but that it used a certificate authority that certain Linux distributions would not be default trust in their wget/curl packages (I guess they use openssl or gnutls or something similar). Browsers like Firefox seem to use their own list and may accept certificates that wget and curl rejected.
Even when technically correct certificates are , we should try to pick a "well known" certificate authority if possible if they are not widely accepted by eg wget/curl in Ubuntu/OSX (to name some common OS we may care about).
-
- removed comment
I would then leave this "wontfix". Old certificate lists on clients are not anything we can tackle from a server side. This has to be fixed by the respective admin. And no - we don't get to choose our certificate authority, at least not through LSU. Plus, with something like heartbleed in mind not even doing that would be "safe".
When you deal with certificates the client has to deal with the trust themselves, otherwise there is no point in doing it.
-
- changed status to resolved
- removed comment
-
- edited description
- changed status to closed
- Log in to comment
- Assignee
- –
- Type
- Priority
- Status
- closed
- Component
- EinsteinToolkit website
- Milestone
- –
- Version
- –
- Votes
- 0
- Watchers
- 0
These are up because they should be up at some point - and point to the same content as the http pages. At the moment they only display test pages and are not advertised. I agree that this should and some point be fixed and that might actually happen soon, but at the moment this is not a major issue. I'll see how fast we can get valid certificates installed.