- changed status to open
- marked as
- removed comment
SSL certificate missing for cactuscode.org (website)
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)
-
-
- changed status to open
- assigned issue to
- removed comment
-
- 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?
-
- removed comment
ah - it is expired.
-
- removed comment
Talked to IT, ticket is open, once the admin is "in" this should be handled.
-
- 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
-
- changed title to SSL certificate expired for svn.cactuscode.org
- removed comment
-
- removed comment
svn.cactuscode.org is fixed. The intermediate certificate chain was missing.
-
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.
-
- changed title to SSL certificate missing for cactuscode.org (website)
- marked as
- changed component to Cactus website
- removed comment
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.
-
- 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.
-
- 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.
-
- changed status to resolved
- removed comment
-
- changed status to closed
- edited description
- Log in to comment
cactuscode.org is also down.