Certificate failure

Create issue
Issue #1061 closed
Erik Schnetter created an issue

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)

  1. Frank Löffler
    • removed 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.

  2. Roland Haas

    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.
    
  3. Frank Löffler
    • 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.

  4. Frank Löffler

    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.

  5. Ian Hinder
    • 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.

  6. Frank Löffler
    • 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.

  7. Barry Wardell
    • 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.

  8. Roland Haas
    • 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).

  9. Erik Schnetter 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.

  10. Frank Löffler
    • 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.

  11. Frank Löffler
    • removed comment

    This has been fixed on QueenBee. Are there other affected machines? Can we close this ticket?

  12. Roland Haas
    • 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

  13. Frank Löffler
    • 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...

  14. Frank Löffler
    • 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.

  15. Log in to comment