I have no background in IT and networking, so this might be kind of stupid but...
I have an SCADA app running on Windows 10, and the app has has it's own website configured.
It has security certificate for the local IP issued. And everything is fine up to this point.
But to access the site from somewhere else we are port forwarding requests from our outer IP to the local address so now the IP doesn't match the one in certificate and it is not working.
What would be the right workaround in these situations, I can't get my head around this problem.
I can issue certificate to the outer ip, but then local network certificates are not working.
Thank you!
Related
In my example I am using https://portmap.io VPN service which is not exactly a pure VPN services but still uses VPN technology to break my ISP restrictions, allowing portforwarding to my own home server running in my android device.
So if I run 193.161.193.99:1200, my website gets browsed. The port 1200 is mapped to my local python server port running on port 1000. Port 1200 is given by the VPN provider.
However, if I try 193.161.193.99 without the port 1200. The portmap VPN official website gets called, cause that's the websites' IP. So basically each user of this VPN services has there own port to work with.
Question: I don't have any public IP totally in my own control to get an SSL certificate, which requires a file upload verification by the CA (CSR). So, it it anyhow possible to get an SSL certificate using 193.161.193.99:1200 ?
Note: Services like zerossl.com accepts to provide a certificate for ipv4 public addresses. So it not always essential to use a FQDN to get a cert.
Yes this is possible, you will need a domain pointing to the VPN/portmap IP and then obtain a SLL certificate from Let's Encrypt for that domain. This can be your own domain or one provided by a Dynamic DNS Service such as Duck DNS.
I'll describe how I have done it with Docker and Duck DNS in detail:
Sign in to Duck DNS, create a subdomain and point it to the VPN/portmap IP, note the token at the top of the page.
Deploy a docker container from LinuxServer.io's SWAG Image
Make sure to provide the required environment variables in your docker-compose.yml (or with docker run command):
- VALIDATION=duckdns
- DUCKDNSTOKEN={your token}
- URL={yourdomain}.duckdns.org
Note: If you want everything behind your VPN, there is a great docker container called gluetun which allows you to run the swag container behind your VPN
You will find your SSL certificates in the /config/etc/letsencrypt/live/{yourdomain}.duckdns.org folder of the SWAG container. Use those for the website/service that is running behind your forwarded port.
The certificates will get updated automatically 30 days before they expire. There is also a PKCS#12-file privkey.pfx, which is needed for services like emby. For more information on SWAG see the LinuxServer.io Docs. You may or may not need another container running that updates the Duck DNS IP periodically, I'm not sure if the SWAG container already does that.
All of this can of course be done without Docker and with your own domain. In this case you will need to map your domain or subdomain to the VPN IP in the DNS Record section of your domain provider. And then use certbot to create certificates for that domain. Docker just automates the renewal part.
I have spent 2 days trying various solutions breaking the stack multiple times... you are my only hope:)
I have setup Plesk on an aws instance and i'm using a webhost license.
Set up a hostname, issued a certificate with lets-encrypt, and works fine when accessing the admin interface on hostname.com:8443
Set up a client domain, issued certificate with let-encrypt, works fine for the front end but when i want to enter admin on clientdomain.com:8443 i get a privacy error. Same thing when trying to access admin with the server ip only as well. In both cases it tries to pull the certificate of "hostname" instead of the cert issued to the client domain.
The goal is to get clients clientdomain.com:8443 and server ip working with ssl or to redirect to hostname.com:8443
I would like to understand what's happening and how can i fix it.
Just in case someone stumbles across the same issue:
Currently this is not possible in Plesk (Obsidian18.0.27) but its being considered
As a temporary solution the best practice is to redirect all clientdomain:8443
requests to hostname:8443 and force https to ensure secure connection.
To achieve this follow these instructions:
https://support.plesk.com/hc/en-us/articles/115001421414
Problem: Since Chrome updated a while back (version 58?), I'm not able to access my computer's development Express web server with HTTPS from a remote machine on the same private LAN.
I have created a self-signed certificate on the server (my laptop), and it works great from the same machine via https://localhost:8383 (the local SSL port).
In the past I could bypass the warning on a remote machine on the same network but it has stopped working.
I've gone through the steps of creating a local secure DNS server on my own router with DD-WRT, and self-signed a new certificate with SAN so I could use a DNS host name to access it without specifying an IP address.
I'm able to get to the page after bypassing the message that warns the site's SSL certificate could not be verified. But that's not good enough because while the site will load, the underlying websocket service I'm using on the same port does not work, and so the application loads but is broken on the remote machine. Still works on the local machine because the certificate is valid.
It seems the issue centers around Websockets within Express.
Any guidance would be greatly appreciated! This is a strictly secure environment that's meant to be used on a private network and it makes no sense for me to spend a bunch of money on a public certificate if that even matters.
Thank you.
It appears that the issue is with mobile Chrome and Safari on IOS -- I can get untrusted SSL certificates to work with websockets from another computer on the same network with the latest versions of Chrome and Safari. But on IOS (ipads and iphones), the page will load after being prompted, but Websockets FAIL to function whatsoever.
I've found a couple other people finding this issue.
My workaround for this problem was to revert away from SSL for my private network and completely avoid self-signed certificates.
In a private environment this is OK.
I'm trying to upgrade a websocket connection ws:// to wss:// using a nginx reverse proxy https://github.com/nicokaiser/nginx-websocket-proxy/blob/master/simple-wss.conf
but I seem to be having trouble with the certificate part. My server is located on the same network as the client. So Ideally I would want my users to log in to "https://example.com" and then the client makes a connection to "wss://192.168.1.xxx:xxxx".
As of now the browsers are blocking it because of NET::ERR_CERT_COMMON_NAME_INVALID. I don't really know to produce a self signed certificate that the browsers will trust on the local network. Googling only gives me answers on how to do it if my server would be accessed using a domain name but I will always connect to a local network IP. Help is appreciated!
To anyone coming across this I managed to solve it using this post outlining the architecture https://support.plex.tv/articles/206225077-how-to-use-secure-server-connections/
What ended up happening was that we set up a url pointing to a server running nginx which parsed the subdomain and redirected the connection to that url. For example: wss://192-168-1-142.mydomain.com redirects to ws://192.168.1.142 which makes the browser trust the connection
Does this work?
Your post is a year old now and browsers have become stricter since then. Usually, a browser will produce 'mixed content' errors if you access HTTP content from a HTTPS page, and the only way to get round this is to change the site settings to allow insecure content, which is scary for users in the face of a big warning message.
If accessing an HTTPS web address redirects to an HTTP local IP address, won't the browser still complain about mixed content?
I have a similar situation to you. I am writing a Progressive Web Application (PWA) to control network music players on a home network. The players only support HTTP but a PWA requires HTTPS for services workers to work and to allow the app to be 'installed'.
My solution is to run a local server on the home network which can talk to the players over HTTP. Then I can access this server over HTTPS from my browser so that the browser itself is not making any HTTP calls.
This works fine if the server is on localhost because localhost is a special case where security rules are relaxed. But if the server is on another machine, how can I create an SSL certificate since (1) it seems that local IP addresses are not allowed in the Subject Alternative Name (SAN) section of the certificate, and (2) I won't know in advance what the IP address of the server will be.
If your workaround works, then the local server can use HTTP instead so I won't need a certificate. The local server can register itself with a web server, and then the browser can connect over HTTPS to the web server, which would redirect to the IP address of the local server over HTTP.
But does this trick work?
this one is driving me mad - hopefully anyone of you can help.
I ordered a cloud server with intention of running multiple customer sites on one server/one ip. Everything is working fine so far, but Im having troubles with SSL.
I added 2 Domains (Domain a, Domain b) via Plesk Panel and installed basic ssl certificates which are working perfectly fine. Both Domains can be accessed via https:// and in the broswer both certificates are shown as valid / secure
Problem: Im getting SSL Issues / Warnings when connecting to the domains mailboxes -> to secure the Plesk Panel a self-signed Certificate was pre-installed.
When I exchange the Plesk self-signed certificate to a certificate for Domain a, Domain a mailboxes are working perfectly fine - but not for Domain b. (obviously). What certificate do I need to install to secure the Plesk Panel and which does not cause any problems with all underlying Domains & their mailboxes?
Will creating a certificate for the servers IP address will do the trick? Is this accepted, even possible or will it result in another warnings? If yes, do I need to create a certificate for xx.xxx.xxx.xxx or xx.xxx.xxx.xxx:8443?
Or is there any other option for running multiple domains on one shared ip?
Any help/guidance is very much appreciated!
Thanks!
Did you mean something like mail.domainb.com or autodiscover.domainb.com for mailbox? Then make sure you have valid SSL certificate for them also not only for mail domain. As far as I know you would not be able to get third-party certificate on IP addresses.
Sorry if I have guessed wrong.