SSL certificate missing for cactuscode.org (website)

Issue #1843 closed
Barry Wardell created an issue

It appears that the SSL certificate for svn.cactuscode.org expired today. This can cause the svn checkout of Cactus thorns (in particular external libraries) to fail.

Keyword:

Comments (14)

  1. Frank Löffler
    • removed comment

    ssl chain is broken on https://cactuscode.org/ (not my doing, will investigate). ssl is fine on https://svn.cactuscode.org/ - so why should svn fail?

  2. Frank Löffler
    • removed comment

    Talked to IT, ticket is open, once the admin is "in" this should be handled.

  3. Ian Hinder
    • removed comment

    For svn.cactuscode.org, SSLChecker says that it is not trusted in all web browsers (https://www.sslshopper.com/ssl-checker.html#hostname=svn.cactuscode.org), and the automated checkout that Jenkins uses says that the certificate is not issued by a trusted authority. This means we have no running tests at the moment.

    For cactuscode.org, SSLChecker says that in addition to not being trusted in all web browsers, there is a hostname mismatch. Indeed, the certificate common name is einsteintoolkit.org, which is incorrect. https://www.sslshopper.com/ssl-checker.html#hostname=cactuscode.org

  4. Frank Löffler
    • removed comment

    svn.cactuscode.org is fixed. The intermediate certificate chain was missing.

  5. Barry Wardell reporter
    • removed comment

    I can confirm that this now works in cases (in particular svn checkouts) where it did not work before the intermediate certificate chain was added.

  6. Frank Löffler

    We never had a certificate for cactuscode.org. All an attempt was leading to was a test page. I tried to redirect the https site to simple http, but that doesn't work, since ssl is handled first in a connection and since there is no certificate in the first place, this already fails before any redirection could take place. I can also not simply have apache not serve that port, since the ET website comes in there too. The only way to gracefully solve this (besides using two physical servers for the two web sites) is to get a certificate. And once you have one you might as well serve it. We also redirect www.cactuscode.org to cactuscode.org. This redirection would also not work when using ssl, so either we get a certificate for both (one just for the redirection), or we live with it.

  7. Ian Hinder
    • removed comment

    We seem to have these certificate issues fairly regularly. I suggest that we discuss how we can improve our processes so that this doesn't happen again.

  8. anonymous
    • removed comment

    For all sites hosted at LSU, certificates have to be from LSU (I specifically asked about that). That means I have to go through CCT support.

    What happened last week: one certificate expired, and (i) I didn't notice (my bad, I am truly sorry), and (ii) while an automatic ticket was opened beforehand for IT support, the person usually in charge was out-of-office, and the fall-back didn't get it done in time. Once he got it done, the chain wasn't correct, and I was out-of-touch for the weekend.

    I will be with IT support in person today (once they are 'in'), to make sure the fall-back also knows the correct installation of certificates; the first-contact person already does.

    The following is a quick script to check on things - of course you have to remember to do it from time to time. https://www.cct.lsu.edu/~knarf/cgi-bin/monitor.cgi

    The issue with cactuscode.org (the website) is unrelated, and not new.

  9. Log in to comment