- removed comment
Certificate failure
Issue #1061
closed
I want to access the ET svn repositories via SourceTree, a nice GUI for managing repositories. This fails because:
Error validating server certificate for 'https://svn.einsteintoolkit.org:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: svn.einsteintoolkit.org - Valid: from Thu, 05 Jan 2012 22:31:55 GMT until Fri, 04 Jan 2013 22:31:55 GMT - Issuer: lsu, edu - Fingerprint: de:b0:88:20:f7:6f:73:df:ed:ad:c2:af:7e:b7:e1:45:13:82:8a:7d (R)eject, accept (t)emporarily or accept (p)ermanently? RA layer request failed: OPTIONS of 'https://svn.einsteintoolkit.org/manifest': Server certificate verification failed: issuer is not trusted (https://svn.einsteintoolkit.org) at /Applications/SourceTree.app/Contents/Resources/git_local/libexec/git-core/git-svn line 2327
Unfortunately, as this is a GUI, I cannot press the "R" key here. To simplify things for me, could you use a trusted certificate instead?
Keyword:
Comments (18)
-
-
- removed comment
-
- changed status to resolved
- removed comment
Please reopen if there still is some issue with the certificate.
-
- changed status to open
- marked as
- changed component to EinsteinToolkit website
- removed comment
This is partially happening again. Now Firefox is happy with the certificate for trac.einsteintoolkit.org but eg. wget is not happy with it
rhaas@horizon:.../EinsteinEOS/EOS_Omni$ wget https://trac.einsteintoolkit.org/raw-attachment/ticket/1070/EOS_Omni_Module.F90.diff --2012-10-16 10:01:49-- https://trac.einsteintoolkit.org/raw-attachment/ticket/1070/EOS_Omni_Module.F90.diff Resolving trac.einsteintoolkit.org (trac.einsteintoolkit.org)... 130.39.21.34 Connecting to trac.einsteintoolkit.org (trac.einsteintoolkit.org)|130.39.21.34|:443... connected. ERROR: The certificate of `trac.einsteintoolkit.org' is not trusted. ERROR: The certificate of `trac.einsteintoolkit.org' hasn't got a known issuer.with curl the error is:
rhaas@horizon:.../EinsteinEOS/EOS_Omni$ curl https://trac.einsteintoolkit.org/raw-attachment/ticket/1070/EOS_Omni_Module.F90.diff curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option. -
- removed comment
As said before, the question of a certificate being trusted is on the client side, not the server. We cannot do something if a client (e.g. OS vendor) decides to use an old list of 'trusted root certificates' or simply doesn't list some there. The certificate of svn.einsteintoolkit.org is valid. See e.g.
http://www.sslshopper.com/ssl-checker.html#hostname=https://trac.einsteintoolkit.org/wiki
The question really boils down to whether your system trusts the "AddTrust External CA Root" certificate by default or not.
Note that you saw a change in behavior because the certificate for trac was renewed (the old was expired) and LSU chose to sign it using "InCommon Server CA" which is signed by "AddTrust External CA Root". The old was signed by "Louisiana State University Issuing CA 1" which is signed by a different root: "GTE CyberTrust Global Root", but since "Louisiana State University Issuing CA 1" also expires Aug next year there wouldn't have been much use in choosing that.
-
- marked as enhancement
- removed comment
It might be interesting to collect information about affected systems and provide solutions for users, i.e. how to tell these systems to trust this root CA.
This is probably going to be a problem primarily on old machines. The root cert in question has a validity window of December 6, 2010 to May 30, 2020 and probably simply wasn't around at the time some of the machines have been installed and thus is not trusted by default there. This is the case for instance on QueenBee.
-
- removed comment
We need to evaluate the end-to-end consequences of what we do, rather than applying a narrow definition of who is right and who is wrong. If some very popular OS has an old list of trusted root certificates, and we require a new one, then we are broken on that OS, and it doesn't really matter whose fault it is. When you buy an SSL certificate, does it come with some indication of the number of widely-deployed systems which it will work with? If you buy a cheaper certificate, will it work with fewer systems? I'm wondering if there is a financial aspect to this.
-
- removed comment
I don't think this is a financial aspect. Root certificates, like any certificate, have a life span. Older systems eventually do not only have a problem because they cannot trust new root certificates, the ones they do trust eventually all expire. For this mechanism to work the list of trusted certificates needs to be updated from time to time. There is no way for us to change this.
You say that this is a problem on a "very popular OS". Do you have more information about that OS? A lot of the tools mentioned (wget, curl) use libraries like openssl under their hood. Which version of openssl is installed there?
My current Debian system (released Feb. 2011) ships with OpenSSL 0.9.8o 01 Jun 2010. This seems to be sufficient for 'our' root certificate. QueenBee on the other hand runs RHEL 4.5, released 2007-05-01 and uses OpenSSL 0.9.7d 17 Mar 2004. Unless the list of certificates was updated in the meantime the list of trusted certificates there is over 8 years old. I don't think you will find so many root certificates that had been valid at that time, will still be in some years and are still used to sign other certificates.
The problem can really only be solved by updating the list of trusted certificates - either (ideally) by the vendor, by the system administrator, or otherwise by the user.
-
- removed comment
If you would like suggestions for alternative SSL certificate suppliers, I can recommend StartSSL as a very good option. They offer free SSL certs which are accepted by any client I have tried them with. Their root certificate is only valid since September 2006, though, so it might not help with QueenBee, for example.
-
- removed comment
Hmm. Its working now for me. Not sure why it failed before. I take it there was no change in certificate during this timeframe (from yesterday). This happened on a debian testing system which does a apt-get update && apt-get dist-upgrade each night (and which has extract certificate package as in http://curl.haxx.se/docs/caextract.html).
As long as this error does not happen during the initial GetComponents stage I am less worried. I would just like to very much make sure that things work during GetComponents (by either adding --no-check-certificate or --insecure to wget/curl).
-
reporter
- removed comment
If we require action from the end user, then we may as well skip certificates, which are supposed to automate this process. The information on Trac is not important enough to be worried about attackers; I'd rather clean up a bit more spam than have to explain people how to disable the security measures we put into place.
As Ian mentioned, we are probably not the only group facing this issue. Large web sites (Google, Amazon, etc.) know how to use certificates in such a way that end users don't receive warnings. I don't care about the technical issues, or how they can be solved with or without root access by the end user. We are paying for a service, and that service is to authenticate us (our server) to our visitors. If this doesn't work, then we paid too much. It's the CA's task to ensure that sufficiently many end users have received their certificate via OS updates or some other mechanism, and if that process takes five years, so be it -- apparently, a root certificate lives for ten years, so there's no problem.
If someone uses a "too-new" root certificate for signing a web site, then this seems rather like a rookie mistake to me.
-
- removed comment
I agree with Erik that we should avoid ssl if it turns out to be a problem on a critical mass of machines. So, which machines are indeed affected? So far I only know about QueenBee, as the problem seems to have disappeared for horizon. Are there other systems where this is a problem? If it turns out that only a small number of machines, especially old HPC systems, are affected we might as well ask the admins to update openssl there - especially if the new LSU certs are not accepted on LSU machines. I opened a ticket for QueenBee.
-
- removed comment
This has been fixed on QueenBee. Are there other affected machines? Can we close this ticket?
-
- changed status to open
- assigned issue to
- removed comment
-
- marked as bug
- marked as
- removed comment
This certificate has now officially expired (it being after Fri, 04 Jan 2013 22:31:55 GMT). It has not been replaced by an up-to-date one. Svn and firefox complain. Frank's script warns (though it apparently does not do the proper time zone conversion): www.cct.lsu.edu/~knarf/cgi-bin/monitor.cgi
-
- marked as
- changed component to Cactus
- removed comment
&%&^, I wanted to have that fixed by now. Well - the good news is that I have the new private .key file. The bad news is that the new .crt is still missing - pinging the relevant local people to send it to me...
-
- changed status to resolved
- marked as
- removed comment
New cert is installed. Please open a new ticket next time something is wrong with the certs.
-
- changed status to closed
- edited description
- Log in to comment
The current certificate is correct. The question whether it is trusted is an issue of the client. Nothing on the server can ensure that an certificate is trusted. However, e.g. consulting various ssl checkers on the svn repositories show "The certificate should be trusted by all major web browsers".
Maybe the trust list on your client are not complete or out of date? There must be a way to add trusted certificates in the worst case.