9

Somehow just today suddenly my seafile client throwed this error. I don't believe its a seafile issue, because my openssl throws the exact same error:

user@nb-user:~$ echo |openssl s_client -connect seafile.mydomain.ch:443
CONNECTED(00000003)
depth=1 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Class 2 Primary Intermediate Server CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/description=5RygJ9fx8e2SBLzw/C=CH/ST=Thurgau/L=Frauenfeld/O=mydomain GmbH/CN=*.mydomain.ch/emailAddress=postmaster@mydomain.ch
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGqzCCBZOgAwIBAgIDAjmGMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0
[... some more lines]
-----END CERTIFICATE-----
subject=/description=5RygJ9fx8e2SBLzw/C=CH/ST=Thurgau/L=Frauenfeld/O=mydomain GmbH/CN=*.mydomain.ch/emailAddress=postmaster@mydomain.ch
issuer=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
---
No client certificate CA names sent
---
SSL handshake has read 3997 bytes and written 431 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 96E1F6B9E123F8F8C1C1E8FB0DBACDBBE76ECB3E2CF5C46C1FD2CF46833C8212
    Session-ID-ctx: 
    Master-Key: 25837E1786B0CC60E676D0694319641CD0887F9CAF48A820F1C0D6ABA6FDE0742551816ACD2A4885B0D3FC143716B1F6
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 88 15 c0 c5 30 04 63 d6-ff 7c 72 c4 12 84 7b d6   ....0.c..|r...{.
    0010 - 73 33 8d 91 7c da ce 22-23 d0 31 fb c1 7f 1c 9c   s3..|.."#.1.....
    [... some more lines]

    Start Time: 1424953937
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
DONE

For me the chain part looks exactly what it should. The apache conf should also be ok:

root@i-can-haz-data ~ # cat /etc/apache2/sites-enabled/seafile.conf

<VirtualHost *:443>

    ServerName seafile.mydomain.ch
    DocumentRoot /opt/seafile/www

    [... seafile specific things]

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    SSLEngine on
    SSLCertificateFile      /etc/ssl/custom/wildcardmydomain.ch.crt
    SSLCertificateKeyFile   /etc/ssl/custom/wildcardmydomain.ch.key
    SSLCertificateChainFile /etc/ssl/custom/wildcardmydomain.ch.chain.crt

    [... seafile specific things]

</VirtualHost>

I cannot find what my issue is... (ca-certificates is installed on my lubuntu 14.04). Their site is not applicable because they linked their Class 1 certificate, but mine is issued by their Class 2.

  • Which operating system? Updated the ca-certificates recently? There were updates for Ubuntu on 2015-02-23. What if you add -CApath /etc/ssl/certs/ or where your certs are stored? Are you maybe missing the root certificate in the chain? – sebix Feb 26 '15 at 13:42
  • Woow, you point me to the right direction. Thank you! echo |openssl s_client -connect seafile.mydomain.ch:443 -CApath /etc/ssl/certs/ -> Verify return code: 0 (ok) DISTRIB_DESCRIPTION="Ubuntu 14.04.2 LTS". System uptodate: 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Package: ii ca-certificates 20141019ubuntu0.14.04.1 – Dionysius Feb 26 '15 at 13:51
19
verify error:num=20:unable to get local issuer certificate

This error by OpenSSL means the program was unable to verify the issuer of the certificate or the topmost certificate of a provided chain. This can happen in some cases, for example:

  • The certificate chain for the certificate wasn't provided by the other side or it doesn't have one (it is self-signed).
  • The root certificate is not in the local database of trusted root certificates.
  • The local database of trusted root certificates was not given and thus not queried by OpenSSL. To give the path to the certificates explicitly, use the -CApath or -CAfile option. For Debian and Ubuntu it is for example:

    -CApath /etc/ssl/certs/
    -CAfile /etc/ssl/certs/ca-certificates.crt
    

    thus resulting in either

    openssl s_client -connect example.com:443 -CApath /etc/ssl/certs/
    openssl s_client -connect example.com:443 -CAfile /etc/ssl/certs/ca-certificates.crt
    

The latter needs more information. There is an open bug report for OpenSSL in Ubuntu since 2009:

Using -CApath seems to set -CAfile to the the default of /etc/ssl/certs/ca-certificates.crt.

No matter what you give as path by -CApath, it may work, because the -CAfile is also set to it's default value (which was empty beforehand). So, don't rely OpenSSL's default behavior on verifying certificates by a the local certificate database, it may be bogus!

  • So you mean, that either my server and my notebook system config is nothing wrong (because its fine with the -CApath option)? Well then, its a fault of the seafile-client notifying me that error? Maybe its this issue: github.com/haiwen/seafile-client/issues/93 - But thank you, marked as solved :) – Dionysius Feb 26 '15 at 14:26
  • I digged more into the behavior of OpenSSL, see my updated post. You may also consider upvoting ;) – sebix Feb 26 '15 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.