SSL unable to connect

[Lysaer 2]

Hi all

Having an issue getting ssl working.

Have tried using the guide here 

But not having any luck, I can get access to my server fine without SSL.

I am using duckdns, I have added the TXT line to the DNS and it verifies fine when creating the certificate.

I have tried using different ports aside from 8920.

I have forwarded ports on my router.

I tried disabling the Windows Firewall.

have attached screenshot of emby settings, sorry about quality for some reason HDR washes out my screenshots, but can see all necessary info

Thank you in advance

 

 

[Luke 42081]

Hi, what exactly happens when you try to connect?

[Lysaer 2]

9 minutes ago, Luke said:

Hi, what exactly happens when you try to connect?

Hi there

Just times out, connection refused, connecting without SSL is perfectly fine though.

I am using the latest beta build if that makes any difference

Thanks in advance

[Q-Droid 989]

Restart your Emby server and attach the newest log.

 

[Lysaer 2]

10 hours ago, Q-Droid said:

Restart your Emby server and attach the newest log.

 

Log attached

I see in the log it says the password is incorrect, I assume this means the password I create for the cert, but I have tried some really basic ones to make sure they are right and it still doesn't seem to work
 

2023-11-02 10:53:03.775 Error App: Error loading cert from C:\SSL\certificate.pfx
    *** Error Report ***
    Version: 4.8.0.56
    Command line: C:\Users\Alex\AppData\Roaming\Emby-Server\system\EmbyServer.dll
    Operating system: Microsoft Windows 10.0.19045
    Framework: .NET 6.0.23
    OS/Process: x64/x64
    Runtime: C:/Users/Alex/AppData/Roaming/Emby-Server/system/System.Private.CoreLib.dll
    Processor count: 8
    Data path: C:\Users\Alex\AppData\Roaming\Emby-Server\programdata
    Application path: C:\Users\Alex\AppData\Roaming\Emby-Server\system
    Internal.Cryptography.CryptoThrowHelper+WindowsCryptographicException: Internal.Cryptography.CryptoThrowHelper+WindowsCryptographicException: The specified network password is not correct.
       at Internal.Cryptography.Pal.CertificatePal.FilterPFXStore(ReadOnlySpan`1 rawData, SafePasswordHandle password, PfxCertStoreFlags pfxCertStoreFlags)
       at Internal.Cryptography.Pal.CertificatePal.FromBlobOrFile(ReadOnlySpan`1 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(System.ReadOnlySpan`1[System.Byte], Microsoft.Win32.SafeHandles.SafePasswordHandle, Internal.Cryptography.Pal.Native.PfxCertStoreFlags)

 

[Q-Droid 989]

Are you able to verify the integrity of the pfx file and password with tools like openssl or certutil?

Edited November 2, 2023 by Q-Droid

[Lysaer 2]

11 minutes ago, Q-Droid said:

Are you able to verify the integrity of the pfx file and password with tools like openssl or certutil?

I'll do that when I get home tonight and let you know

[Lysaer 2]

On 02/11/2023 at 12:04, Q-Droid said:

Are you able to verify the integrity of the pfx file and password with tools like openssl or certutil?

Sorry, have been crazy busy, just only had a chance to sit down and test, results from openssl using the command

openssl pkcs12 -in certificate.pfx -password pass:a8TqL*oE$FUod@fXWTP#kgL^egB@%Wp^Crw%Hw8#dc6^CL -info -nokeys

MAC: sha1, Iteration 1
MAC length: 20, salt length: 8
Mac verify error: invalid password?

To generate the cert that is the password I used, as follows

@[member="Echo"] off
le64 --key account.key --csr domain.csr --csr-key domain.key --crt certificate.csr --domains ****.duckdns.org --generate-missing --handle-as dns --export-pfx a8TqL*oE$FUod@fXWTP#kgL^egB@%Wp^Crw%Hw8#dc6^CL --live
pause

I tried using a simpler password to see if that made a difference and it did not, I did notice when I run the command it initially says this, could that be causing an issue in the generation?

'[member' is not recognized as an internal or external command,
operable program or batch file.

D:\SSL\le64>le64 --key account.key --csr domain.csr --csr-key domain.key --crt certificate.csr --domains ***.duckdns.org --generate-missing --handle-as dns --export-pfx a8TqL*oE$FUod@fXWTP#kgLegB@Hw8#dc6CL --live
2023/11/10 20:23:31 [ Crypt::LE client v0.39 started. ]
2023/11/10 20:23:31 Loading an account key from account.key
2023/11/10 20:23:31 Loading a CSR from domain.csr
2023/11/10 20:23:33 Registering the account key
2023/11/10 20:23:33 The key is already registered. ID: 1391977226
2023/11/10 20:23:35 Received domain certificate, no validation required at this time.
2023/11/10 20:23:35 Requesting issuer's certificate.
2023/11/10 20:23:35 Saving the full certificate chain to certificate.csr.
2023/11/10 20:23:35 Exporting certificate to certificate.pfx.
2023/11/10 20:23:35 The job is done, enjoy your certificate!

D:\SSL\le64>pause
Press any key to continue . . .

Thanks in advance

[Q-Droid 989]

One of the problems I see is your overly complex passphrase that is using characters which may be interpreted by the shell and screwing things up.

If you look at both passwords you can see something missing from the output:

Quote

openssl pkcs12 -in certificate.pfx -password pass:a8TqL*oE$FUod@fXWTP#kgL^egB@%Wp^Crw%Hw8#dc6^CL -info -nokeys

D:\SSL\le64>le64 --key account.key --csr domain.csr --csr-key domain.key --crt certificate.csr --domains ***.duckdns.org --generate-missing --handle-as dns --export-pfx a8TqL*oE$FUod@fXWTP#kgLegB@Hw8#dc6CL --live  <-- %Wp^Crw% is missing

 

You could try the openssl test again but using the second password from the output instead: a8TqL*oE$FUod@fXWTP#kgLegB@Hw8#dc6CL

Another option is to use a long password with alphanumeric characters only while keeping in mind that some symbols are interpreted by the shell whether on Linux or Windows.

Quoting the password may help but at this point you don't really know which was used to create the keystore.

 

Edited November 10, 2023 by Q-Droid

[Lysaer 2]

6 minutes ago, Q-Droid said:

One of the problems I see is your overly complex passphrase that is using characters which may be interpreted by the shell and screwing things up.

If you look at both passwords you can see something missing from the output:

You could try the openssl test again but using the second password from the output instead: a8TqL*oE$FUod@fXWTP#kgLegB@Hw8#dc6CL

Another option is to use a long password with alphanumeric characters only while keeping in mind that some symbols are interpreted by the shell whether on Linux or Windows.

Quoting the password may help but at this point you don't really know which was used to create the keystore.

 

I did try with a simpler password, but will give it another try, I didn't notice the missing part, thanks for pointing that out

[Luke 42081]

Let us know how that goes. Thanks.

[Lysaer 2]

13 hours ago, Luke said:

Let us know how that goes. Thanks.

I made an absurdly simple password and it works, so will adjust on a variation on that, evidently it was too overly complex, thanks to @Q-Droidfor pointing that out