SSL Connections not working

[knowenoughtobedangerous 6]

Try as I might, I can't get HTTPS connections to my windows server working so can't link it to Alexa.

I've followed the advice in the knowledge base, using SSL for Free to create a cert, and then the SSLShopper site to convert it to a PFX file.  Emby rejects it with an 'invalid network password' error (see 18:11:43.830 in embyserver 1.txt)

Using the XCA app to convert the same cert to a .p12 file gets past that error, but now the log shows an "Error creating port map" entry (see 17:56:13.203 in embyserver.txt).  This time, Emby shows the WAN port as 8920 rather than 8096, but all I get from Chrome is a "This page isn’t working" error. 

My router has ports 8096 and 8920 both mapped to my windows PC.  Connecting via Emby Connect finds me, but as in insecure connection.

Any ideas, please?

embyserver.txt embyserver 1.txt

Edited March 6, 2022 by knowenoughtobedangerous

[Luke 42080]

Hi, perhaps try recreating the pfx with a new password.

[Happy2Play 9782]

Is the cert on your OneDrive?  Looks like Emby can't communicate directly to that location.

[knowenoughtobedangerous 6]

Tried a new, shorter password @Luke,  and tried moving the files off Onedrive @Happy2Play. Same problems as before, but thanks both for your suggestions.  Any more thoughts?

[Happy2Play 9782]

All previous topics seem to point to the method the cert is made, or the password used (special characters).

 

 

[knowenoughtobedangerous 6]

A small step forward: created .pfx and .p12 files with a new, simple (ie not very secure) and emby gets past the 'invalid network password' error for the .pfx but both now give me the same "Error creating port map" log entry.

Creating the cert with SSL for Free (ZeroSSL) is as simple as it gets, so I can't see what I could have done wrong there.  I use the auto-genrate CSR option. The domain matches that in emby (media.the-addisons.com) and I have an A-record set in my DNS to point to my external IP address, so that should(?) be OK. 

What does "Error creating port map" actually mean?  Might this not be cert-related at all?

Hope you are having a good sleep.

[pwhodges 2012]

Is Emby set up (in the network settings) to use UPnP to create the port mapping in the router?  If you've done that manually, perhaps that setting should be turned off.

Paul

[knowenoughtobedangerous 6]

Thanks for the input, Paul.  Yes, the UPnP setting was on.  Had no effect when I turned it off.  Turned it back on again and deleted the mapping in my router but that made no difference either.  Restarted Emby after each change.

[knowenoughtobedangerous 6]

I'll add that connecting to my local IP address (https://192.168.1.100:8920) lets me in, but not with an SSL connection.  Ditto if I quote my WAN IP address.

Edited March 7, 2022 by knowenoughtobedangerous

[rbjtech 5284]

Unless you have a network route to your WAN address from internally on your network (called hairpinning) then you cannot connect to the WAN address.

If emby is showing https://YOUR_DOMAIN:8920 on the dashboard - then it has accepted the cert and is listening on port 8920 for an https connection.

If you have a VPN you can try using that (as that will be seen as an external/WAN address), or use a mobile/cell on the 4G/5G network (no wifi) to test.

You can check the 'listening' state by using the following powershell commands

To test on the emby server itself -

PS C:\Users\richa> test-netconnection localhost -port 8920

ComputerName     : localhost
RemoteAddress    : ::1
RemotePort       : 8920
InterfaceAlias   : Loopback Pseudo-Interface 1
SourceAddress    : ::1
TcpTestSucceeded : True

To test on the same LAN - use the server IP address -

PS C:\Users\richa> test-netconnection 192.168.30.100 -port 8920

ComputerName     : 192.168.30.100
RemoteAddress    : 192.168.30.100
RemotePort       : 8920
InterfaceAlias   : vEthernet (Internal RBJ Home VLAN30)
SourceAddress    : 192.168.30.1
TcpTestSucceeded : True

Edited March 7, 2022 by rbjtech

[knowenoughtobedangerous 6]

Thanks @rbjtech  Yes, the dashboard is showing port 8920 and both those PS tests worked from my local LAN. 

From a remote PC then, the PS script on my WAN IP address also works and, as before, accessing https://<my WAN IP>:8920 gets through, but as an insecure connection.  ie, I get the warning from Chrome about the connection being insecure and it shows the login page at "https://<my WAN IP>:8920/web/index.html#!/startup/manuallogin.html?serverId=c78c2ab2e06e4185aa0610b89a7a087e"

Back to this being a certificate problem? 

[rbjtech 5284]

1 minute ago, knowenoughtobedangerous said:

Thanks @rbjtech  Yes, the dashboard is showing port 8920 and both those PS tests worked from my local LAN. 

From a remote PC then, the PS script on my WAN IP address also works and, as before, accessing https://<my WAN IP>:8920 gets through, but as an insecure connection.  ie, I get the warning from Chrome about the connection being insecure and it shows the login page at "https://<my WAN IP>:8920/web/index.html#!/startup/manuallogin.html?serverId=c78c2ab2e06e4185aa0610b89a7a087e"

Back to this being a certificate problem? 

and you have it set to 'preferred' https connection correct - ie it is falling back to http ?

If you set it to 'Required for all remote connections' - does it then fail to connect ?

[Happy2Play 9782]

Connecting via WANIP is going to fail as the cert is not for an IP address, correct?  I know mine fails and I get "NET::ERR_CERT_COMMON_NAME_INVALID".

[rbjtech 5284]

14 minutes ago, Happy2Play said:

Connecting via WANIP is going to fail as the cert is not for an IP address, correct?  I know mine fails and I get "NET::ERR_CERT_COMMON_NAME_INVALID".

The FQDN is above H2P, so I'm making the assumption the OP is using that for anything https..

[rbjtech 5284]

8 hours ago, knowenoughtobedangerous said:

Creating the cert with SSL for Free (ZeroSSL) is as simple as it gets, so I can't see what I could have done wrong there.  I use the auto-genrate CSR option. The domain matches that in emby (media.the-addisons.com) and I have an A-record set in my DNS to point to my external IP address, so that should(?) be OK. 

Actually -re reading this - why are you creating a DNS A record on your local DNS for the WAN address ?   Your DNS should be using public DNS servers to resolve the name - this should not be done internally.  I can resolve the above FQDN fine as your ISP/Registrar would have created it for you when they created the domain.  Maybe this is confusing things.

edit - to note - this WAN port is OPEN on 8920

Edited March 7, 2022 by rbjtech

[knowenoughtobedangerous 6]

Bang on.  Putting in the domain name rather than the IP address gets me through on a secure connection.  So far, so great.

So now I'm moving on to why I needed SSL in the first place:  the Alexa Emby skill insisted on one.  Now to try getting that working

[knowenoughtobedangerous 6]

Using an A record because I also have a 'normal' web site with a hosting provider and the normal www DNS records point to that.  So a created the cert for media.<my domain> and pointed the A record for that to my Emby server WAN IP

 

[rbjtech 5284]

7 minutes ago, knowenoughtobedangerous said:

Using an A record because I also have a 'normal' web site with a hosting provider and the normal www DNS records point to that.  So a created the cert for media.<my domain> and pointed the A record for that to my Emby server WAN IP

 

ok - but this is on your cert suppliers web 'portal' - correct - which is public DNS.  You used the term 'my DNS' above which I took to mean your personal DNS server ... sorry for the confusion.. !

Glad everything is ok.

Certs always use FQDN's - IP's can change, FQDN's cannot

Edited March 7, 2022 by rbjtech

[knowenoughtobedangerous 6]

ah, sorry to mislead you. My web site is with Weebly but my domain is registered with 123-Reg so I have to set up my DNS records with them.