Handshake / Verification error

Help
1

Hi guys,

I am running a Emby server which I am trying to access remotely using a Let's Encrypt certificate.

I used Certbot to create the pem-files and converted them to pfx using the following command:

openssl pkcs12 -export -out /tmp/cert.pfx -inkey */privkey.pem -in */cert.pem -certfile */chain.pem

I am not using any password protection for the pfx file.

When using Chrome / Edge I can access the WebUI without any issue but with some Emby Apps it simply doesn't work and I get a handshake error in the Emby log:

System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception. ---> Interop+OpenSsl+SslException: SSL Handshake failed with OpenSSL error - SSL_ERROR_SSL. ---> Interop+Crypto+OpenSslCryptographicException: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown

I also tried the following commnand:

openssl s_client -connect mydomain:8920

and get this output: https://paste.ubuntu.com/p/jHy758D6q5/

OpenSSL version on the system was 1.0.2, installing 1.1.0 didn't help.

Why am I getting that verification error?

If you need further information please let me know!

2

Hi @neik,

I was able to identify your server name from the certificate in your paste. (We generally do insist on people providing their server names in order to get help on this forum.)

It appears from your paste and from my own test that you’re not serving the intermediate (chain) certificate from Let’s Encrypt, which is probably why the certificate validation fails. Perhaps that chain.pem file didn’t end up making it into your PKCS12 file, or perhaps your server expected to receive it in some other format?

3

Hi @schoen,

sorry for missing that part.

Emby only has the option to add a PKCS12 file so it should not be expecting an other format.
Is there anything wrong with the command I used to create the PKCS12 file?

4

I’m not particularly familiar with openssl pkcs12 but your command looks similar to other people’s commands. Maybe try -CAfile instead? And make sure that */chain.pem really exists where you expect it?

There is also a -chain option, but I don’t know if it’s necessary.

5

You can tell when you’ve gotten it right with your openssl s_client command—you should see two certificates in the chain rather than just one. For example, for letsencrypt.org itself, the chain as displayed by that tool looks like this:

 0 s:/CN=www.letsencrypt.org
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
6

I tried a couple of different commands using -CAfile, using fullchain.pem instead of chain.pem etc. but at the end all had the same issue.

I couldn’t get the -chain option to work I pointed to to chain.pem and fullchain.pem but none worked.

7

Hi @neik,

I’ve installed (well, it is the portable version) Emby Server on a Windows 10 machine and exported a valid cert to pkcs12:

openssl pkcs12 -export -out certificate.pfx -inkey privkey.pem -in cert.pem -certfile chain.pem -password pass:

I’ve configured Emby server to use it and checking the TLS connection it is showing the right chain:

openssl s_client -connect localhost:8920
[...]
---
Certificate chain
 0 s:/CN=my.domain.tld
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
[...]

You should check whether the chain is the right one using above openssl s_client command because maybe the problem is not related to this issue anymore.

Cheers,
sahsanu

8

Hi @sahsanu,

just found this topic over at Emby Forum: https://emby.media/community/index.php?/topic/54709-problem-getting-lets-encrypt-ssl-cert-to-work-on-embyserver-dotnetcore/

Apparently it isn’t an issue of Let’s Encrypt but an Emby issue. Using the latest Emby on Ubuntu you get this certificate issue, using Arch Linux apparently works flawlessly.

What I forgot to mention in the first place: The certificate was working flawlessly with an older version of Emby (mono-version) but after updating to the latest (dotnet-version) this issue began.

2 Likes
9

Aha, that makes much more sense! I’m glad you were able to track it down.

10

Hi guys, I had a deeper look at this.

When I do curl https://domain:8920 -v I get this output:

  • Trying <server_ip>...
  • TCP_NODELAY set
  • Connected to domain (<server_ip>) port 8920 (#0)
  • ALPN, offering http/1.1
  • Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/certs/ca-certificates.crt
    CApath: /etc/ssl/certs
  • TLSv1.2 (OUT), TLS header, Certificate Status (22):
  • TLSv1.2 (OUT), TLS handshake, Client hello (1):
  • TLSv1.2 (IN), TLS handshake, Server hello (2):
  • TLSv1.2 (IN), TLS handshake, Certificate (11):
  • TLSv1.2 (OUT), TLS alert, Server hello (2):
  • SSL certificate problem: unable to get local issuer certificate
  • Closing connection 0
    curl: (60) SSL certificate problem: unable to get local issuer certificate
    More details here: curl - SSL CA Certificates

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.
HTTPS-proxy has similar options --proxy-cacert and --proxy-insecure.

I can solve this issue by pointing to the lets-encrypt-x3-cross-signed.pem that is provided by Let's Encrypt over here: Chain of Trust - Let's Encrypt

The output of curl https://domain:8920/ --cacert /tmp/lets-encrypt-x3-cross-signed.pem -v looks like this:

  • Trying <server_ip>...
  • TCP_NODELAY set
  • Connected to domain (<server_ip>) port 8920 (#0)
  • ALPN, offering http/1.1
  • Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
  • successfully set certificate verify locations:
  • CAfile: /tmp/lets-encrypt-x3-cross-signed.pem
    CApath: /etc/ssl/certs
  • TLSv1.2 (OUT), TLS header, Certificate Status (22):
  • TLSv1.2 (OUT), TLS handshake, Client hello (1):
  • TLSv1.2 (IN), TLS handshake, Server hello (2):
  • TLSv1.2 (IN), TLS handshake, Certificate (11):
  • TLSv1.2 (IN), TLS handshake, Server finished (14):
  • TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
  • TLSv1.2 (OUT), TLS change cipher, Client hello (1):
  • TLSv1.2 (OUT), TLS handshake, Finished (20):
  • TLSv1.2 (IN), TLS change cipher, Client hello (1):
  • TLSv1.2 (IN), TLS handshake, Finished (20):
  • SSL connection using TLSv1.2 / AES256-GCM-SHA384
  • ALPN, server did not agree to a protocol
  • Server certificate:
  • subject: CN= domain
  • start date: Apr 10 20:38:12 2018 GMT
  • expire date: Jul 9 20:38:12 2018 GMT
  • subjectAltName: host "domain" matched cert's "domain"
  • issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
  • SSL certificate verify ok.
    GET / HTTP/1.1
    Host: domain:8920
    User-Agent: curl/7.55.1
    Accept: /

< HTTP/1.1 302 Found
< Location: web/index.html
< Server: Microsoft-NetCore/2.0
< Date: Sat, 12 May 2018 07:47:51 GMT
< Transfer-Encoding: Chunked
<

  • Connection #0 to host domain left intact

I wanted to install the cross-signed.pem by following this instructions: How do I install a root certificate? - Ask Ubuntu

But I get this error:

syntax error at /usr/local/bin/c_rehash line 15, near "= ;"
syntax error at /usr/local/bin/c_rehash line 16, near "= ;"
Execution of /usr/local/bin/c_rehash aborted due to compilation errors.

I have no clue how to solve this, how about you?

11

You shouldn’t need to trust the intermediate certificate systemwide if you can fix the problem with Emby and have Emby serve the intermediate certificate, as it ought to. It seems like this was diagnosed earlier in this thread and the errors with clients in general won’t go away until that problem has been fixed.

If you do want to add the LE X3 intermediate locally as a root as a workaround, but it’s failing, I’d suggest asking about that on one of the Ubuntu forums.

1 Like
12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.