I have a new laptop. I am connected from my home wifi network via VPN to my company network. In the old one when I enable manual proxy (needed for some scan app to record internet traffic) there are no issues. In the new one once I change to manual proxy, access to all internet and intranet sites fail due to non trusted certificates (no issue when not using manual proxy). The failures are the same in all browsers. Both laptops have windows 10.
"security certificate is not trusted by your computer's operating system"
Your PC doesn’t trust this website’s security certificate.
The hostname in the website’s security certificate differs from the website you are trying to visit.
Error Code: DLG_FLAGS_INVALID_CA
DLG_FLAGS_SEC_CERT_CN_INVALID
Any idea?
Related
The Problem
browsers have no problem accessing my domain's website (https protocol) from a private network (home WiFi, personal hotspot), but if I try to access from a public network (my University's WiFi or Ethernet network, Costco WiFi, etc.), I get the following error message (happens on Chrome, FireFox, Edge, Safari (error messages are a bit different on Safari and FireFox)):
NET::ERR_CERT_AUTHORITY_INVALID
terp.app normally uses encryption to protect your information. When
Chrome tried to connect to terp.app this time, the website sent
back unusual and incorrect credentials. This may happen when an
attacker is trying to pretend to be terp.app, or a Wi-Fi sign-in
screen has interrupted the connection. Your information is still
secure because Chrome stopped the connection before any data was
exchanged.
You cannot visit terp.app right now because the website uses HSTS.
Network errors and attacks are usually temporary, so this page will
probably work later.
(By the way, it would give me the "because the website uses HSTS" message even before I implemented HSTS)
Background
I have set up an Apache2 web-server on my Linux VPS (Ubuntu 20.04). I recently configured everything so a domain I've purchased is accessible and working on this server:
DNSs redirect to server (domain is with Google Domains; VPS is hosted by Hostinger)
Redirect is achieved with custom records, which are two A records:
1st A record: Host Name: terp.app | Data: <VPS IP address>
2nd A record: Host Name: www.terp.app | Data: <VPS IP address>
Apache server set up with virtual hosts
set up an SSL certificate through letsencrypt.org (certbot)
I selected the option during this process to redirect http to https
configured DNS certificate authority authorization (CAA) so only letsencrypt.org-issued certificates are accepted
Achieved with one CAA record:
CAA record: Host Name: terp.app | Data: 0 issue "letsencrypt.org"
I enabled Strict Transport Security (HSTS)
Not sure if the fact that it is a .app domain has some sort of an impact
Bottom line, when I use ssllabs.com/ssltest/, I get an A+ grade: everything checks out. https connection has zero issues on private networks. I can confirm the problem from public networks doesn't have to do with a captive portal since I'm able to access any other website from these public networks.
Looking for a Solution
Yes, I know that I can navigate to chrome://net-internals/#hsts, and enter my desired domain name into "Delete Domain Security Policies." This is unequivocally not the solution I'm looking for. I want my site to work for users without them needing to do something like that. Other high-profile websites obviously don't have this issue, so...
How can I ensure my users will be able to access my site even when they're on public networks? Could it be because I'm using letsencrypt.org?
I've looked over the Internet and haven't found any solution. My task is to prevent access to the Internet by Google Chrome if the system is not running an OpenVPN connection. So, as the result it will:
Block Internet access if OpenVPN is not connected.
Allow Internet access if OpenVPN is connected.
Any ideas? The platform is Windows 10. With other types of VPN connections, it was possible to stick to the specific interface and to configure Windows Firewall. The target machine is remote one and is manipulated by TeamViewer so the best case is to block only Google Chrome.
I've found a workaround. You need to switch your main network to Private profile. When you connect through OpenVPN your system works in Public profile. Thus you can configure the firewall to allow connections only through the Public profile. I this case, when Google Chrome runs through Private profile it will not allow the connection.
I want an app I am testing to use Win (10) OS system proxy settings. I'm watching packets on the proxy and see HTTPS browsing traffic on Chrome (I've installed a self signed cert on Win).
I can also see a few other OS requests coming through the proxy server. For some reason though, some apps don't pay attention to the system proxy settings.
Is there any way to force all connections through the proxy server? The app I'm testing uses Qt - QWebView. I found a reference here that you need to change the source to use a proxy. This won't work for me as I only have access to the production binary for this test.
How can I force an OS proxy connection, or otherwise route that traffic through my proxy?
Note my OS is in a virtual machine.
Edit: I'm wondering if editing the hosts file could route the traffic for a particular URL to my Proxy? I'm trying Acrylic but I'm not having any luck.
I am working to setup my application to watch calendar events through Google's Calendar API. In doing so I must setup a "Push" endpoint on my server that has a valid SSL certificate (not self-signed).
My production environment is running on Heroku so setting up an SSL cert was easy using Expidited SSL. I have two CNames setup in GoDaddy, one for my production application and one for my development environment tunneled through ngrok. I'm using the paid ngrok feature of white labeled domain tunneling (dev.mydomain.com).
Host Points To
www saga-1234.herokussl.com
dev ngrok.com
The problem is that my ssl certificate is recognized when you hit the production application (www.mydomain.com), but it uses ngrok's certificate when you visit the development application (dev.mydomain.com).
How can I setup my ngrok tunnel to use my ssl certificate?
Ngrok's white labeled domain does not support HTTPS if you are using your own domain. Simply because it serves it's own certificate, where you need to serve your domain's. That's why you are getting certificate mismatch issue.
Here's what you could do to watch calendar events on your dev machine:
Point ngrok.mydomain.com to another server, let's say a new EC2
micro instance
Point wildcard CNAME to ngrok.mydomain.com
Compile ngrok server and client to use your certificate (rather than
ngrok.com)
Run the ngroku-server on EC2 instance
On your dev machine config the client to use ngrok.mydomain.com instead of ngroku.com
Run ngrok -subdomain=dev 80
Your local dev machine's 80 port should be accessible via https://dev.mydomain.com
This is really cool and is very helpful when debugging Google's webhooks, which require valid HTTPS and a verified root domain name.
Another interesting trick is to use CloudFlare's universal SSL to have a valid https://dev-machine.mydomain.com pointing to your dev machine without purchasing a certificate. The steps are exactly the same except that you need to issue your own certificate for ngrok client-server communications and use CloudFlare's Flex SSL for dev-machine.yourdomain.com.
ngrok has a new feature that tunnels and terminates SSL. Thus you can use your own domain and HTTPS. No need to open ports in your router or PC. They call it TLS Tunneling. The following is a link to a GitHub repos that describes how to do it.
How to use your own domain to access your home PC over the internet. Use HTTPS without raising SSL errors.
We have two different ldap providers in two different physical office locations.
When I connect my laptop to one location and I 'retrieve from port' (in Websphere 6.1) to import the SSL cert of the ldap provider, I can authenticate to the respective ldap with no problems. If I take my laptop to the other office (that uses the other ldap provider by default) and I plugin my laptop, my WAS on my laptop will not start because it says 'no trusted SSL cert found'.
If I 'retrieve from port' again and re import the cert then it works again.
Note that my WAS always try to connect to one ldap, it simply has no use for the other one.
If I go back to the other office I get the same error until I reimport from that location. The ldap connection point is ldap.example.com:636 and is pingable in both locations with the same FQDN.
But when pinged it resolves to a different IP address in each office location. Why do I see that behavior?
Are SSL Certs somehow bound to a specific IP address?
If yes, then I need to maintain a different set of certs for each office location, right?
Note that, there is no way to adjust the DNS servers to resolve the hostname to the same IP address, I checked.
Can someone provide some insight?
SSL certificates are bound to a 'common name', which is usually a fully qualified domain name but can be a wildcard name (eg. *.example.com) or even an IP address, but it usually isn't.
In your case, you are accessing your LDAP server by a hostname and it sounds like your two LDAP servers have different SSL certificates installed. Are you able to view (or download and view) the details of the SSL certificate? Each SSL certificate will have a unique serial numbers and fingerprint which will need to match. I assume the certificate is being rejected as these details don't match with what's in your certificate store.
Your solution will be to ensure that both LDAP servers have the same SSL certificate installed.
BTW - you can normally override DNS entries on your workstation by editing a local 'hosts' file, but I wouldn't recommend this.
The SSL certificates are going to be bound to hostname rather than IP if they are setup in the standard way. Hence why it works at one site rather than the other.
Even if the servers share the same hostname they may well have two different certificates and hence WebSphere will have a certificate trust issue as it won't be able to recognise the certificate on the second server as it is different to the first.
Most SSL certificates are bound to the hostname of the machine and not the IP address.