Since your checks with openssl s_client fail that confirms that intermediate Let's Encrypt certificate is missing from the root cert store used by openssl (and by python). Python uses system openssl as encryption backend. That functions most likely load the full chain, not just the certificate. Since it's written in python I assume the developer doesn't do any direct interaction with openssl and uses python's functions instead. I'll test how "SSL_CTX_add_extra_chain_cert" works anyway. I believe the root certificates rarely change to not care about. Why do you resist putting the intermediate certificate into NZBGet's CertStore-file? You can make a copy of this file under another name to avoid overwriting by NZBGet updates. That's actually the right thing to do and I'll add this code into nzbget. The results are as if you were adding all chain certificates into SecureCert-file. However, if I init the internal root cert store before loading server certificate into NZBGet's web-server, openssl finds necessary intermediate certificates in cert store and adds them into certificate chain. This way the user can specify whatever intermediate cert they'd want (Let's Encrypt can't be the only cert having this problem):Ĭurrently NZBGet uses root cert store (option CertStore) only in client mode, to verify certificates sent by servers to which NZBGet connects. Instead of concatenating, if a separate intermediate chain file is specified (ssl.ca I think, otherwise the DST Root CA from Let's Encrypt's website), can it be added to the chain via "SSL_CTX_add_extra_chain_cert"? According to the docs, it's currently falling back to the Mozilla CA store, which doesn't contain it for whatever reason. Let's Encrypt certs expire and renew every 30 or so days, thus overwriting the previous cert. I don't know how sustainable adding the intermediate certificate is to the end of the current certificate, mainly because it will have to be done every month or so. Have you tried Firefox on another machine? Apparently Firefox doesn't clean the certificate cache (even in Private mode): I just tried it on 3rd machine (clean VM with Firefox 54.0 portable), same certificate error page. I'm still surprised your Firefox install doesn't give the error (even though Chrome and Edge work fine). Older NZBGet version were using SSL_CTX_use_certificate_file and combined certificates did not work. NZBGet uses openssl function SSL_CTX_use_certificate_chain_file. Whether the combined certificate will work in hydra depends on how hydra loads the certificate. openssl s_client -connect :6791 works too. Now fetching in NZBGet works and we can use the default cacert.pem coming with NZBGet. Opened the test certificate (which we use in NZBGet web-server) in a text editor and at the end of file added the content of Let's Encrypt intermediate certificate.Restored original cacert.pem (removed Let's Encrypt).It will also work for any other certificate signed by Let's Encrypt. Added the Let's Encrypt intermediate certificate into cacert.pem used in NZBGet - now fetching in NZBGet works.It's strange that it worked in Firefox because NZBGet uses the root cert store (cacert.pem) obtained from Mozilla web-site.That certificate isn't in NZBGet root cert store (option CertStore, by default file cacert.pem in nzbget directory). The reason for this error: the certificate is signed by an intermediate certificate from Let's Encrypt.Result: NZBGet reports an error, similar to the one reported by openssl (CertCheck=yes in nzbget). Added an URL to NZBGet download queue, the URL refers to NZBGet web-interface ( ).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |