Certbot generated SSL certificate (converted by OpenSSL running on Cygwin64) doesn't work with emby.

[oneembyuser 4]

Probably this is a duplicate of this thread, but I couldn't find any way around it, so I'm posting this. Due to the recently implemented limitation on ZeroSSL's free account, I tried some alternatives. I got one of them working, but this working method (done by le64.exe) relies on DNS acme challenge, which is something I'd like to avoid. The other method (certbot generated certificate converted by openssl running on cygwin64) doesn't work with emby for some reason. These are exactly what I did and what I got.

The method that works properly - DNS acme challenge based certificate (le64.exe)

1. On an elevated cmd prompt,

le64.exe --key account.key --csr domain.csr --csr-key domain.key --crt certificate.csr --domains "MYDOMAIN.COM" --generate-missing --handle-as dns --export-pfx [MYPASSWORD] --live

2. The above command gave me DNS ACME challenge. Upon the completion of the challenge, it generated pfx certificate.

Saving the full certificate chain to certificate.csr.
Exporting certificate to certificate.pfx.
The job is done, enjoy your certificate!

3. I loaded the certificate on "custom ssl certificate path" (under the setting - network), and input [MYPASSWORD] to "certificate password" and of course clicked the save and restarted the emby service. At first, it didn't work for several minutes, but after some time, it started work properly.

 

The method that doesn't work but I want this one - http acme challenge based certificate (certbot generated certificate converted by openssl running on cygwin64)

1. Installed the certbot from https://dl.eff.org/certbot-beta-installer-win32.exe

2. Stopped the emby service

3. On an elevated cmd prompt,

certbot certonly --standalone -d MYDOMAIN.COM

4. The above command gave me several prompts (email input, ToS agreement, mailing agreement). After that, it gave me 4 pem files in C:\Certbot\live\MYDOMAIN.COM.

5A. I converted the file by using this command. This command did not give me password input prompt as it is already given.

openssl pkcs12 -export -out /cygdrive/g/SSL/emby.pfx -inkey /cygdrive/c/Certbot/live/MYDOMAIN.COM/privkey.pem -in /cygdrive/c/Certbot/live/MYDOMAIN.COM/cert.pem -certfile /cygdrive/c/Certbot/live/MYDOMAIN.COM/chain.pem -password pass:[MYPASSWORD]

5B. I converted the file by using this command. This command gave me password input prompts twice.

openssl pkcs12 -export -out /cygdrive/g/SSL/emby.pfx -inkey /cygdrive/c/Certbot/live/MYDOMAIN.COM/privkey.pem -in /cygdrive/c/Certbot/live/MYDOMAIN.COM/cert.pem -certfile /cygdrive/c/Certbot/live/MYDOMAIN.COM/chain.pem

6. I loaded the certificate on "custom ssl certificate path" (under the setting - network), and input [MYPASSWORD] to "certificate password" and of course clicked the save and restarted the emby service. I also checked the password by using this command, and the password has been correctly set according to openssl.

openssl pkcs12 -in /cygdrive/g/SSL/emby.pfx -noout

But I couldn't connect to http://MYDOMAIN.COM on any of my devices but I could connect to http://MYDOMAIN.COM on every devices. Same goes for local machine. http://localhost works while https://localhost doesn't. Emby gave me this error on its log.

Quote

Error App: Error loading cert from G:\SSL\emby.pfx
*** Error Report ***
    Version: 4.5.4.0
    Command line: C:\Users\*******\AppData\Roaming\Emby-Server\system\EmbyServer.dll -service
    Operating system: Microsoft Windows 10.0.19042
    Framework: .NET Core 3.1.9
    OS/Process: x64/x64
    Runtime: C:/Users/*******/AppData/Roaming/Emby-Server/system/System.Private.CoreLib.dll
    Processor count: 8
    Data path: C:\Users\*******\AppData\Roaming\Emby-Server
    Application path: C:\Users\*******\AppData\Roaming\Emby-Server\system
Internal.Cryptography.CryptoThrowHelper+WindowsCryptographicException: Access denied
 at Internal.Cryptography.Pal.CertificatePal.FilterPFXStore(Byte[] rawData, SafePasswordHandle password, PfxCertStoreFlags pfxCertStoreFlags)
       at Internal.Cryptography.Pal.CertificatePal.FromBlobOrFile(Byte[] rawData, String fileName, SafePasswordHandle password, X509KeyStorageFlags keyStorageFlags)
       at System.Security.Cryptography.X509Certificates.X509Certificate..ctor(String fileName, String password, X509KeyStorageFlags keyStorageFlags)
       at System.Security.Cryptography.X509Certificates.X509Certificate2..ctor(String fileName, String password)
       at Emby.Server.Implementations.ApplicationHost.GetCertificate(CertificateInfo info)
    Source: System.Security.Cryptography.X509Certificates
    TargetSite: Internal.Cryptography.Pal.Native.SafeCertContextHandle FilterPFXStore(Byte[], Microsoft.Win32.SafeHandles.SafePasswordHandle, Internal.Cryptography.Pal.Native.PfxCertStoreFlags)

I'm not sure what caused this problem, but I've been converting certificate from ZeroSSl by using the openssl running on cygwin, and those certificate haven't give me any problem (and the last one still works as of today). I tried blank password on 5B. but to no avail. What am I missing?

One odd thing I notice is, when I copied the 4 pem files from C:\certbot\live\MYDOMAIN.COM to the home folder of cygwin, and tried converting there, openssl gave me this error and did not produce any pfx file. This error do not appear if I don't move or copy the file and convert from the original location.

Quote

Can't open privkey.pem for reading, No such file or directory

34359738384:error:02001002:system library:fopen:No such file or directory:crypto/bio/bss_file.c:69:fopen('privkey.pem','r')
34359738384:error:2006D080:BIO routines:BIO_new_file:no such file:crypto/bio/bss_file.c:76:
unable to load private key
 

Not sure if it helps, but C:\certbot\live have README file, which contains this.

Quote

This directory contains your keys and certificates.

`[cert name]/privkey.pem`  : the private key for your certificate.
`[cert name]/fullchain.pem`: the certificate file used in most server software.
`[cert name]/chain.pem`    : used for OCSP stapling in Nginx >=1.3.7.
`[cert name]/cert.pem`     : will break many server configurations, and should not be used
                 without reading further documentation (see link below).

WARNING: DO NOT MOVE OR RENAME THESE FILES!
         Certbot expects these files to remain in this location in order
         to function properly!

We recommend not moving these files. For more information, see the Certbot
User Guide at https://certbot.eff.org/docs/using.html#where-are-my-certificates.

So I've tried the following as well, and it isn't going anywhere.

openssl pkcs12 -export -out /cygdrive/g/SSL/emby.pfx -inkey /cygdrive/c/Certbot/live/MYDOMAIN.COM/privkey.pem -in /cygdrive/c/Certbot/live/MYDOMAIN.COM/cert.pem -certfile /cygdrive/c/Certbot/live/MYDOMAIN.COM/fullchain.pem -password pass:[MYPASSWORD]

openssl pkcs12 -export -out /cygdrive/g/SSL/emby.pfx -inkey /cygdrive/c/Certbot/live/MYDOMAIN.COM/privkey.pem -in /cygdrive/c/Certbot/live/MYDOMAIN.COM/fullchain.pem -certfile /cygdrive/c/Certbot/live/MYDOMAIN.COM/cert.pem -password pass:[MYPASSWORD]

and the one below gave me "No certificate matches private key" error right off the bat on converting phase.

openssl pkcs12 -export -out /cygdrive/g/SSL/emby.pfx -inkey /cygdrive/c/Certbot/live/MYDOMAIN.COM/privkey.pem -in /cygdrive/c/Certbot/live/MYDOMAIN.COM/chain.pem -certfile /cygdrive/c/Certbot/live/MYDOMAIN.COM/cert.pem -password pass:[MYPASSWORD]

 

[Luke 42080]

Hi, that is quite a process. Thanks for the investigation. Regarding the access denied error, did you see this?

https://stackoverflow.com/questions/49071730/x509certificate2-access-denied-exception-if-use-ecc-certificate

[rbjtech 5284]

Just curious as I don't use CertBot (I use Win ACME) - but how is the 2nd method verifying your ownership of the domain ?

[oneembyuser 4]

1 minute ago, rbjtech said:

Just curious as I don't use CertBot (I use Win ACME) - but how is the 2nd method verifying your ownership of the domain ?

I think it temporarily acts like a web server (i.e. when it's challenged by the CA, it creates a file and show it to the CA through http).

[rbjtech 5284]

Is it worth comparing the final pfx certs (DNS vs HTTP) for the Domain, CA's details etc to ensure they are the same ?

ie using the built in Cert Checker in Windows - certutil -dump YOURDOMAIN.COM.pfx

 

[oneembyuser 4]

I tried that on both working and non-working certificate. They have different serial numbers, cert hashs, issue/expiry date&time but other than that they're about the same.

[rbjtech 5284]

ok - it's a little difficult diagnosing this one without the files - so lets go back to the error message in the log file.

It says - "Internal.Cryptography.CryptoThrowHelper+WindowsCryptographicException: Access denied"

My immediate thought is the password does not match.  Have you, just for testing, created a very basic low complexity password version using say just 8 lowercase letters only ?  The reason I say this is I have seen compatibility issues before with extended ASCII sets and special characters before.

 

[Q-Droid 989]

Access denied is definitely an issue but the big question is what's causing it?

But your openssl commands don't look right to me. Some of the options seem to be mismatched. Like stated above by rbjtech run a test with a simple password, no special characters that could be interpreted.

Try:

openssl pkcs12 -export -out [full-path-to-pfx] -inkey [full-path-to-private-key] -in [full-path-to-fullchain] -password pass:[MYPASSWORD]

Verify with but don't share or post output:

openssl pkcs12 -info -in [full-path-to-pfx] -nodes

 

[oneembyuser 4]

 

8 hours ago, rbjtech said:

ok - it's a little difficult diagnosing this one without the files - so lets go back to the error message in the log file.

It says - "Internal.Cryptography.CryptoThrowHelper+WindowsCryptographicException: Access denied"

My immediate thought is the password does not match.  Have you, just for testing, created a very basic low complexity password version using say just 8 lowercase letters only ?  The reason I say this is I have seen compatibility issues before with extended ASCII sets and special characters before.

 

I changed the password to abcdefgh and tried the password on emby settings. But it yielded the same result. If I use the wrong password on the working certificate (generated by le64.exe), it produces the different error which is The specified network password is not correct. instead of Access denied.

8 hours ago, Q-Droid said:

Access denied is definitely an issue but the big question is what's causing it?

But your openssl commands don't look right to me. Some of the options seem to be mismatched. Like stated above by rbjtech run a test with a simple password, no special characters that could be interpreted.

Try:

openssl pkcs12 -export -out [full-path-to-pfx] -inkey [full-path-to-private-key] -in [full-path-to-fullchain] -password pass:[MYPASSWORD]

Verify with but don't share or post output:

openssl pkcs12 -info -in [full-path-to-pfx] -nodes

 

The command also produced the same error. Both (your and my) command passed the verification and produced exactly the same verification output.

[Q-Droid 989]

Have you tried putting the same pfx in a different place/path? It sounds like ownership/permission might be different when created from a Cygwin shell. Check/change the attributes from the Windows side. Make sure the full path is accessible by the user running Emby.

 

 

[rbjtech 5284]

11 hours ago, Q-Droid said:

Have you tried putting the same pfx in a different place/path? It sounds like ownership/permission might be different when created from a Cygwin shell. Check/change the attributes from the Windows side. Make sure the full path is accessible by the user running Emby.

 

 

Agree 100% here - Access Denied in this sense must mean access to the pfx file itself, not the contents of it are being denied.  The password test proved your password on the working Cert (good test ).   

Also - How is is Emby running ?  A service (using a service account ?) or on the logged in desktop account ?  Check this has read permissions to the file.

[oneembyuser 4]

Sorry. I forgot about this to this date. Now, 3 months is up and time for renewal.. This time, I tried the second method, and then look up the file permission of the pfx file. Cygwin indeed messed up the file permission. After changing the permission, the second method also works. Now I can fully automate the process, thanks.

For someone who're trying to use SSL certs with this combo, this is exactly what I did.

1. Download and install certbot
https://dl.eff.org/certbot-beta-installer-win32.exe

2. Stop the emby service

3. On an elevated cmd terminal, run this command after modifying MYDOMAIN.COM to suit your need; This command will throw you several prompts (email input, ToS agreement, mailing agreement). After that, it'll throw 4 symbolic links of 4 pem files (default path: C:\Certbot\live\MYDOMAIN.COM / default real file path C:\Certbot\archive\MYDOMAIN.COM)

certbot certonly --standalone -d MYDOMAIN.COM

4. Convert the file using OpenSSL. I ran it on Cygwin, but if you use Cygwin, you might have to change the file permission afterward. If you want to do it on Cygwin, change DRIVELETTER/FOLDER/FILENAME as well as MYDOMAIN.com (appears 3 times) and [MYPASSWORD] to suit your need.

openssl pkcs12 -export -out /cygdrive/DRIVELETTER/FOLDER/FILENAME.pfx -inkey /cygdrive/c/Certbot/live/MYDOMAIN.COM/privkey.pem -in /cygdrive/c/Certbot/live/MYDOMAIN.COM/cert.pem -certfile /cygdrive/c/Certbot/live/MYDOMAIN.COM/chain.pem -password pass:[MYPASSWORD]

5. If you already setup your emby to point that pfx file and have entered correct password, all you need to do is start up the emby service again (and if you did it on cygwin, change the file permission. go to right click - properties - security - advanced. and do the same thing on any regular file. and then copy exactly).

[Luke 42080]

That's great info. Thanks for following up !