Emby not switching over to HTTPS after inputting certs and info

[RaisonDetre72 5]

Followed this guide on the forum (though I used No-IP cert instead of SSLForFree).  Converted to PKCS #12, and input all info on my server.  Got the prompt everything was updated successfully and to reboot the server, though after rebooting it's still showing as the old 8096 / regular HTTP.  One thing I did notice is that the guide says I should be putting in a .pem file, though PKSC#12 files are .pfx.  Not sure if that matters.

I've tried accessing via https://192.168.1.150:8920, and get "Connection refused", even with my Windows Firewall turned off.

Attached is screenshot of settings I'm using to implement SSL, and screenshot showing it's still on 8096/http.

[seanbuff 1318]

1 hour ago, RaisonDetre72 said:

the guide says I should be putting in a .pem file, though PKSC#12 files are .pfx.  Not sure if that matters

.pfx should be fine.

Few things to check:

• Have you port-forwarded 8920 to your Emby Server host in your router?
• You should try accessing via the domain name that the cert was generated for, not the IP.
• Have you tried changing the connection mode to: "Required for all connections" -- just to see if there's a difference?

As always, you're best to supply an Emby Server log file to see if its complaining about your certificate (eg. permissions, format, etc.)

[RaisonDetre72 5]

N00b error on my part for not checking the log. *doh!* So looking at the log, it is throwing an error (I'll paste at the bottom).  Not sure what password it's referring to, as the password I set when generating the PKCS was copy / pasted directly, and I've re-entered it just in case.  I was also wondering if it may be some Windows permissions error, so I tried moving the pfx cert to just the root of the C drive, but it's still throwing the error when restarting the server.

Internal.Cryptography.CryptoThrowHelper+WindowsCryptographicException: Internal.Cryptography.CryptoThrowHelper+WindowsCryptographicException: The specified network password is not correct.
       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) 

[seanbuff 1318]

The user that is running Emby Server needs to have read permissions on the cert file. Sometimes the root of the drive is not the best location for that.

Also, as a test are you able to regenerate the cert using a basic password to rule out any special characters causing an issue?

[RaisonDetre72 5]

Alright, problem solved!  It looks like it was special characters in the password that was causing it (for the record, there were @ and & symbols in it).  Also fyi, changing the directory or the file's permissions did not have an impact.  So it is now showing that I'm on HTTPS/8920.  Huzzah!

Your assistance is much appreciated.  Thank you.   

[justinrh 260]

Is the issue with special chars an Emby issue or cert generation issue?

It is hard for me to believe that special chars still cause issues these days, but even my bank doesn't allow a space!

[Happy2Play 9784]

12 minutes ago, justinrh said:

Is the issue with special chars an Emby issue or cert generation issue?

It is hard for me to believe that special chars still cause issues these days, but even my bank doesn't allow a space!

I have no issues with special characters !@#$ on my stable or beta cert passwords but may be specific characters.