I am running a web server (Wordpress) locally using XAMPP (using Apache) and forwarding it to my Cloudflare-hosted domain using a Cloudflared tunnel. I am having an issue with the certificate when connecting over my domain.
I have a certificate I received from Cloudflare which is valid for my domain installed in XAMPP's location for its certificate, and I know that it is being sent with the HTTPS result. Also, my "SSL/TLS encryption mode" on Cloudflare is "Full (Strict)".
When connecting from the browser, I get a 502 Bad Gateway error, and Cloudflared prints this error: error="Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared: x509: certificate is valid for *.example.com, example.com, not localhost where example.com is my domain.
If I go to
http://example.com or https://example.com, I get the above error.
http://localhost, the website loads but does not load any of the resources, since Wordpress loads the resources by querying the domain, https://example.com/path/to/resource.
https://localhost, the same as above happens, but Chrome also give me a warning that the certificate is not valid.
Here are the ingress rules in Cloudflared's config.yml.
ingress:
- hostname: ssh.example.com # I haven't gotten this one to work yet.
service: ssh://localhost:22
- hostname: example.com # This is the one having a problem.
service: https://localhost
- service: https://localhost
What I believe is happening is that Cloudflared receives the certificate which is valid for my domain (*.example.com, example.com) and then tries to execute the ingress rule by going to https://localhost, but the certificate is not valid for localhost. I don't think I should just get a certificate which is valid for localhost AND example.com. Do I need one certificate (valid for localhost) to be returned whenever http(s)://localhost is called and another (valid for example.com) that Cloudflared checks when it tries to execute an ingress rule involving example.com? If so, how do I do this?
I solved it by using the noTLSVerify option in Cloudflared's config.yml. When a client connects to my domain, it goes like this:
Client > Cloudflare > Cloudflared instance running on my machine > Origin (which also happens to be my machine: https://localhost)
The certificate sent back by the Origin was not valid for the address Cloudflared was accessing it from, localhost, but by adding these lines to config.yml,
originRequest:
noTLSVerify: true
I think Cloudflared does not check the certificate received from the origin, although it still returns the certificate to Cloudflare, which checks it against my domain.
Related
I need some direction for projects i made.
I have an existing node-red in local server that send data using websocket to my domain in my hosting. Everything is working fine over http but the problem occured when i used https for my domain. I used websocket ws: before then i changed it wss: to work over https but it still did not work because i realize i need SSL certificate for my local server too. Then, I used self-signed certificate for my local server. It works but i have to manually input my local server DDNS in my browser to allow wss first then back to my hosting domain, i can't expect the users to do this.
I used DDNS on my local server because i have no static IP. I try to call for my ISP for provide static IP but it can't be done in the near future.
Because i have no static IP i can't register domain and i can't use CA Certificate for local server SSL.
My question is:
Is there a way to allow ws to work over https?
If not, is there a way to allow unsafe wss on my domain page over a button or a prompt when user go to my page? so user don't have to manually input my local server DDNS.
Or other way you may suggest.
No, Websocket connections are bootstrapped over HTTP, Secure Websocket connections over HTTPS. The TLS session is setup by the HTTPS connection.
It's not clear what you are asking here. But the only way to get a self signed certificate to work with a websocket connection is to install that certificate into the browsers trusted certificate store before trying to access the site. The browser will not prompt to trust a certificate for a websocket connection.
You can use Letsencrypt with a proper Dynamic DNS setup. This is where you have a fixed domain name and a script on your machine that updates the IP address the domain name points at. The hostname will stay the same so the certificate issued will always have the correct CN/SAN entry. Letsencrypt certificates are signed by a trusted CA certificate that will already be present in your browser.
I have a domain served at server A and I have set up an A-record to server B.
For http://mypage.com all works fine.
But there is also SSL on the domain. On server B there are a few virtual hosts set up. One of which has an SSL virtual host (443), theirpage.com. If I now go to https://mypage.com I end up at theirpage.com.
If I set up mypage.com MUST I have the SSL certificate from server A available for this new specific ssl-virualhost? The provider at server A does not share their ssl-certificates...
Assuming:
Server A - DNS only, no web services.
Server B - Web server.
The following is extreme oversimplification of what actually happens. For simplicity we exclude all caches, networking and application complexity.
What happens on the client:
User navigates to mypage.com (HTTPS)
Browser/OS does a lookup of who mypage.com is; receives the IP
Browser attempts to establish secure connection with IP of a webserver.
It is at this point browser will look at the SSL certificate provided by your web server. That certificate must be signed by trusted authority and have a valid alternate name of mypage.com. Not signed or name does not match to what user typed into the browser you will receive a certificate error.
If the certificate passed:
Browser will complete establishing connection
Browser will request a content named mypage.com
Browser displays content revived from the web server
In this scenario only web server must have a valid certificate, prooving to the client that it is indeed the server client attempts to connect to.
HTTP Scenario is similar, but connection is not secured and site will load. Most of the websites setup redirect request on HTTP calls, forcing the user's browser repeat it's request via HTTPS protocol.
I observed a site example.com has a cname mapping with mysite.com. Both example.com and mysite.com have ssl certificates.
Correct if I am wrong?
When a browser tries to connect https://example.com it checks DNS and finds it has cname mapping with mysite.com and connect to mysite.com web server directly.
When I observed browser it has ssl certificate for example.com domain. I am facing problem in understanding this case.
If request did not go to example.com web server how could browser get ssl certificate of example.com
or my cname mapping understanding is wrong?
or example.com private and public keys are shared with mysite.com webserver ?
DNS and TLS operate completely independent of each other.
TLS is used, among other things like encryption, to verify the identity of a server against its FQDN (Fully qualified domain name). This is done by checking whether the server in question is able to present a certificate, containing the FQDN, signed by a trusted certification authority (CA).
DNS is used to resolve host names to IP addresses, in order to establish network connections (like TCP connections) on a lower layer. How this resolution takes place is completely transparent to other components, like TLS. It does not matter whether the name resolution involves A, AAAA, or the mentioned CNAME record - in our context the input is always a single hostname, the output is always one (or more) IP addresses. Intermediate results, like CNAME mappings, are essentially discarded once name resolution is done.
This means that the TLS client always uses the FQDN initially requested by the user, regardless of any CNAME mappings, to verify the certificate. How to present a valid certificate is up to the server - sticking to your example, the server behind FQDN mysite.com will have to present a certificate valid for example.com in order for the client to accept it. How the private/public key of this certificate is generated, and whether it is shared with other certificates or servers, does not matter.
We would have to explicitly attach the SSL certificates of both the domains to the webserver/load balancer for both the domains to support HTTPS.
To understand this, it's useful to be aware of and understand SNI
When multiple websites are hosted on one server and share a single IP
address, and each website has its own SSL certificate, the server may
not know which SSL certificate to show when a client device tries to
securely connect to one of the websites. This is because the SSL/TLS
handshake occurs before the client device indicates over HTTP which
website it's connecting to.
Server Name Indication (SNI) is designed to solve this problem. SNI is
an extension for the TLS protocol (formerly known as the SSL
protocol), which is used in HTTPS. It's included in the TLS/SSL
handshake process in order to ensure that client devices are able to
see the correct SSL certificate for the website they are trying to
reach. The extension makes it possible to specify the hostname, or
domain name, of the website during the TLS handshake, instead of when
the HTTP connection opens after the handshake.
From: https://www.cloudflare.com/en-gb/learning/ssl/what-is-sni/
I have just installed a wildcard ssl certificate on a custom domain, this is working fine for any subdomain of *.example.com. I can verify that the correct ssl certificate is being issued.
However the problem is with www. which is issuing the Bluemix certificate not my own certificate.
In the browser i am getting "Your connection is not private"
This server could not prove that it is www.example.com; its security certificate is from *.eu-gb.mybluemix.net. This may be caused by a misconfiguration or an attacker intercepting your connection.
I am guessing that the problem is with Bluemix, how can i get Bluemix to serve up my certificate for www, baring in mind that it is serving up my certificate for other subdomains.
All help will be greatly recieved
I have fixed this issue, the problem was with the DNS setup.
The key piece of information for me, was that my dns was point to 2 IP's of Bluemix 5.10.124.142, and 5.10.124.141, therefore only serving up my certificate on one, and the Bluemix default certificate on the other
From googling how to add a custom domain, i added a CNAME record to point to *****.eu-gb.mybluemix.net and an A record to 5.10.124.142
This is wrong, i need to change my CNAME record to be my actual domain now.
I have a IIS 7 server hosting a few different sites. Recently I purchased and installed a SSL certificate to one of the site. Both http and https binding are setup with host header xxx.com and www.xxx.com.
But now i discover that other site with no SSL is loading the certificate and show the untrusted cert error when accessing through https.
Can i know how I can stop other non SSL site from loading the certificate?
Thank you.
I assume that
you are using the server on a single IP address
provide service for multiple names on this single IP address
have configured SSL for some of the names but not for others
This means, that
The server is listening on this specific IP address for SSL connections.
The server can only decide after receiving the initial SSL request from the client (ClientHello) which certificate it should use. The Client hash to use SNI (server name indication) to tell the server which hostname it expects. Most newer clients support this but for example IE8/XP does not.
Since the server has to listen for SSL connections on this IP address it can happen, that it receives a SSL request for a hostname, where it has not certificate configured. In this cases a server could do the following:
Use some other certificate it has configured. This is what your server is doing. This results in an error on the client about an invalid certificate since the name in the certificate does not match the expected name.
Simply close the connection or issue some SSL error. This would result in an SSL handshake error on the client which browsers usually display in a way so that end users are not able to understand what's going on. For the browser the situation is simply a server error and the server is not able to give the browser more detailed information (this is not part of the SSL protocol).
If you don't like any of these two problems you must serve the non-SSL hosts from a different IP address than the SSL hosts, so that the server will not even listen on the SSL port for connections for the non-SSL hosts.
I hope this explanation helps with your problem. If you have now specific questions about the configuration of the server to achieve the outlined solution you should ask them at serverfault.com instead.