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.
Related
When accessing https://mcgillcrm.com some users are seeing this in chrome: ERR_SSL_PROTOCOL and this is firefox: SSL_ERROR_RX_RECORD_TOO_LONG
But it only happens when they access the site through a specific ISP (Videotron).
When the site is accessed via a hotspot or when connected to a different ISP it works fine and it also works if the user is using Windows machine instead of a Mac.
I verified SSL labs, checked port 443 and compared against another site where it doesn't throw this error and everything seems fine.
We have a 301 redirect towards https and I double checked that users really type https:// when accessing the web-site, but it still doesn't work.
How is the connection done to the ISP vs. how is the connection done to a different ISP or mobile network
Mac user connects to the wireless modem: SSL errors come up
Mac user connects to the wireless mobile hotspot: No error comes up
Update 12 Oct 2022
We re-installed a new certificate from scratch and this one is not showing 'self signed' anywhere. Will see if it helps.
HTTPS is end to end encryption and integrity protection. It should not depend on the ISP used by the client. If it is specific only to the ISP or specific clients then something is messed up at their end, like some middleboxes or antivirus interfering with the connection, a captive portal asking the client to acknowledge some rules first, DNS resolution pointing to a different IP then yours etc. There is nothing you can do from the server end against this, since maybe the server is not even reached by the client.
Problem turned out to be with safebrowse.io which was somehow caching the incorrect certificate (clearing SSL cert in chrome didn't help).
It in turn affected other browsers also like Firefox. So once the incorrect cert was cached it flagged it globally as an unsafe site..
It looks like it was cached inside the logged in users chrome profile (Google Workspace account).
Solution was to login as Guest > Go to web-site > Click 'Proceed anyway' > Restart Chrome
This looks like a serious design flaw with safebrowse.io, why/how it caches SSL certificates in Chrome profile is unclear. This should have worked while accessing the web-site in Chrome incognito but it didn't..
I am creating a new LAN server with https enabled in my organization, and I am having a hard time figuring out how to work out SSL Certs. Manually creating a cert and adding it to a specific computer's browser allows that computer to access the local https site, but installing it manually on each computer in the network is not realistic. Is there any way to use a group policy to add a new one to all the computers, or use an existing SSL cert to validate my website? There is one existing one for the organization already, which I noticed is on all the computers on the network already, but I'm not sure how to use it.
This may be a stupid question, but basically I just need a local server to use https. Any help would be great.
We have been battling with an issue where I've been getting a 5006 error using "SagePay Server" for 24 hours after moving a nopcommerce site to a new server with a different IP address.
We use a free cloudflare service with SSL enabled on Cloudflare in Full SSL mode and then a self signed certificate on our server so the connection is always secured end to end. This was also the same on the old server.
When moving servers we simply updated the IP address in couldflare to point at the new IP address but we started getting 5006 errors during the checkout process...
SagePay support told us they could not connect to our notification URL which was using SSL. Our server showed no attempt from their server to connect to ours yet SapePays log files show an "internal_error" with no more useful information.
However it is possible to the call the notification URL passed to SagePay from a browser and it works without issue.
After talking with SagePay on several occasions it would seem the SagePay system does not support websites / traffic using SSL with SNI which means they can not connect to the notification URL over SSL.
In a time when IPv4 addresses are fast running out I would imagine more and more people will start to use SNI for SSL so they can run multiple sites using SSL from one IPv4 address - a massive oversight on SagePay's part me thinks.
Contrary to JaxUK, I can confirm SagePay does support SSL/TLS with SNI. Hope this helps someone
I have SSL working fine in production but have some issues locally.
When I run the site it opens 2 tabs, one http:// and one https://
I want to just use the http:// tab locally for testing. When I go to a page that requires https I get the error:
Unable to make a secure connection to the server. This may be a
problem with the server or it may be requiring a client authentication
certificate that you don't have
I have added the certificate to:
Persona/Certificates
Trusted Root Certification Authorities/Certificates
Intermediate Certification Authorities/Certificates
Everything works fine locally when I use the https:// tab.
Do I need to add the certificate somewhere else too?
Using SSL certs locally is always a challenge. When the website opens, it's likely using the loopback IP (127.0.0.1) which will always (rare exceptions, perhaps, that I can't think of) give a certificate error, because the cert is bound to a domain name, not an IP. Ideally you'd probably want to not use your websites real SSL cert locally anyway for security reasons.
You can use a self signed cert for localhost, which should work:
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/32bc5a61-1f7b-4545-a514-a11652f11200
Also, I just blogged a code snippet we've used before -- in short, it just avoids using SSL for local connections and otherwise lets you define which pages/folders should otherwise be SSL protected...
http://www.structuretoobig.com/post/2013/02/19/Skipping-SSL-Connections-Locally.aspx
Context
I developed an application deployed in a Glassfish 3.1. This application is accessed only by https and sometimes it must connect to third-party webservices located out the customers networks. The customer have other applications inside his network; mine is only a new one "service".
Topology approximation
Big-ip F5 is the ssl end point. The customer have in this device the valid certificate
IIS redirects by domain to the respective service
glassfish is the machine with the application (over, of course, a glassfish 3.1)
How it works
When a user try to connect to _https://somedomain the request arrives to the F5 where the SSL encryption ends; now we have a request to _http://somedomain. In the next step F5 redirects this request to the IIS and this, finally, redirects to glassfish. This petitions are successfully processed.
Points of interest
I've full control over glassfish server and S.O. of the vm where it is located. Not other applications are or will be deployed on this server; it's a dedicated server for the app and some services it needs. The Glassfish runs on a VM with a Debian distribution as S.O. This VM is provided by a VM Server but I don't know the brand, model, etc. The glassfish have the default http listeners configuration.
I don't have any more information about network and other devices and i can't access to
any configuration file of any other device. I can't modify any part of the network for my own but maybe ask, suggest or advice for a change. Network's behavior should not change.
Actually users reach the application without problem.
The used certificate is a simple domain certificate trusted by Verysign
The customer have no idea of how to solve this.
The problem
All the third party WS the application must access have an unique https access and, in some cases, the authentication required is mutual (two-way) and here we find the problem. When the application wants to connect to WS with mutual ssl authentication it sends the glassfish local keystore configuration targeted certificate. Customer wants, if possible, use the same cert for incoming and outcoming secure connections. This cert is in the F5 and i can't add to the glassfish keystore because if I do this I would be breaking Verysign contract requirements. I've been looking for a solution at google, here(stackoverflow), jita,... but only incoming traffic solutions I've found. I understand that maybe a SSL proxy is required but I haven't found any example or alternative solution for the outcoming ssl connections.
What I'm asking for
I'm not english speaker (isn't obvious?) and maybe i doesn't use the correct terms in my search terms. I can understand that this context can be a nightmare and hard to solve but I will stand... The first think I need is to know if exists a solution (or solutions) for this problem and if it (or they!) exist where or how can I find it/them. I've prepared different alternatives to negotiate with the customer but I need to known the true. I've spent tones of hours on this.
There are a couple of solutions.
1)pay verisign more money for a second "license/cert". They will be happy to take your money for the "privilege". :)
2)Create a different virtual server listening on 443 which points to a pool that has your client's server address as the pool member. Then on the virtual server, attach a serverssl profile that is configured to use the same cert you are using for the incoming connections. Then the F5 would authenticate with the same cert along with your app server would not need a client cert installed. Also, if they need to initiate a session to you, you would have to setup a virtual server with a clientssl profile that uses the same cert and requires a client cert to connect.
If your destinations may not be static addresses, then an irule(s) would have to be created to deal with that. Can be handled in 10 or later code with a DNS call in the irule and setting a node for the session to go.