I have a site where i have ssl created by letsencrypt, but there is a problem with no sni ssl. Is it confugired ok?
https://www.ssllabs.com/ssltest/analyze.html?d=watcheds.com
Site looks good https://watcheds.com .
I
Your site is almost certainly hosted on a virtual host with many other sites on the same IP address. As such, HTTPS won't work without SNI because the server can't know which virtual host the client wants to connect to. The raw data in a TCP connection only has the IP address and port. The HTTP data is all in the packet content, which is encrypted in HTTPS.
SNI access works via HTTPS because the desired site is passed unencrypted and in the clear, allowing the server to properly route the incoming connection without access to your site's private SSL keys. Without SNI, the server would need to decrypt the incoming HTTPS request before knowing where to route it, and this would require the server to have access to your site's private keys.
And if the server were hosting many virtual hosts, without something like SNI it wouldn't know which set of private keys to use...
Related
Guess this is the only post ever where I start with: "My SSL connection works but I don't know why".
I have a setup where the domain name and wildcard certificate lie on server A, and I want to use a subdomain of that domain to proxy requests to server B on another machine somewhere on the internet. Server B is currently only reachable via an IP, so I actually did not expect this to work, because SSL-certificates are based on domain names.
My setup is as follows (example):
Server A domain: www.production.io
Server A Subdomain: cus1.production.io
Server B IP: 65.23.523.12
Apache config for http of cus1.production.io:
RequestHeader set X-Forwarded-Proto "https"
ProxyPreserveHost On
Redirect / https://cus1.production.io/
Apache config for https of cus1.production.io:
ProxyPass / http://65.23.523.12/
ProxyPassReverse / http://65.23.523.12/
Calling cus1.production.io shows the application on 65.23.523.12 but with a secured connection (green lock) in the browser though the webserver on Server B does not offer https connections nor does it provide an SSL certificate.
Although the connection between a client and the "proxying" Server A is secure, the data transferred to the actual application is not. So this is actually a fraud.
Question: How do I make sure a secure connection will be applied between Server A and Server B?
It's not really "fraud", it's just that the SSL/TLS connection is ensured between the browser and Server A. The browser has nothing to do with Server B: Server A is the client to Server B.
If you can, set up SSL/TLS on Server B. Even if it's only accessible with an IP address, you could create your internal CA or a self-signed certificate. (That certificate should have this IP address in a SAN entry of IP address type.)
Then, you can use mod_ssl's SSLProxy* options to configure how Apache Httpd (on Server A) behaves as a client to server B (i.e. when it's a reverse proxy).
Typically, you'll need to set SSLProxyCACertificateFile (to point to your internal CA cert or that self-signed cert) and use SSLProxyCheckPeerName.
In short, it's up to you to make sure.
What you've just described is a common way of configuring SSL setups, where you have one set of servers that handle the secure connection to the browser, then they proxy the requests to another server, often just with http. This is known as ssl termination.
Usually this connection is done within a secure network, the servers hosting the certificates can be accessed from the internet, but the servers they forward to are not, so they don't proxy back across the internet. However, there is nothing in theory to prevent this if your servers aren't configured properly.
I'm setting up a redirect server where users can input an alternate domain name, point DNS to my server, and configure it to redirect to their servers. My plan is to use the default virtual host in Apache to handle all the requests, route everything to a web application that looks up the place to redirect in a database.
I'd like to support HTTPS, but I can't figure a way to dynamically specify the certificate and key for each site. The only way that I know of configuring HTTPS is by putting directives for SSH certs and keys into a virtual host specific to that domain name. I'd like to store the certificates and keys in the database along with the domain name and have Apache call my web app during the SNI handshake.
Is it possible to have flexible, dynamic SNI under Apache?
My situation:
I want to run a webserver on a device in an unknown network. Requests on port 80 or 443 will be forwarded to this device from the global ip.
The device regularly posts its IP address to a server on the web and it is saved on this server.
Is it possible to access this device via https without much trouble?
The problem of course is, that the ip can change and a SSL certificate needs to have a hostname.
Edit: The device doesn't have a domain assigned to it that I could use for a certificate. Is it maybe possible to use a domain I own and reroute that to the dynamic ip without changing the header?
As far as I understand it that would make using https possible
The common wisdom of SSL certificates being associated with one IP address is misleading. An SSL certificate is issued for the domain name, not the IP address. The issue with IP addresses stems from the details of the HTTPS protocol, and namely just the issue of name resolution. An HTTP server can host many different sites for many different domains, all on the same port and IP address. It knows which site is being requested based on an HTTP header.
Now, with HTTPS, the server first needs to negotiate a secure SSL connection before any HTTP headers are exchanged. The issue therefore is that it can't know which certificate for which domain it's supposed to use to negotiate a secure connection, because it hasn't yet had a chance to talk to the client about the domain it'd like to visit.
There are actually mechanisms for name negotiation before encryption in later versions of the HTTPS protocol, but the practical problem is that older clients do not support it yet (stare at IE6).
So the practical solution is to reserve one IP address and/or port for each HTTPS site, because then there's no issue of multiple name resolutions. One IP/port is reserved for one specific HTTPS site and in extension for one SSL certificate.
Which means, as long as your server is only serving one HTTPS domain, its IP address can change as often as it wants; there's no issue there.
There is no problem with dynamic IP. In SSL certificate you store a static hostname (domain.com), no IP address.
The scenario is this: On side "A" where I stay I can only use 443 for HTTPS from the browser, no other port is enabled for HTTPS requests. In the side "B" I have multiple HTTPS sites in different LAN servers behind one IP address to Internet.
Is a possible way to do something to access the multiple HTTPS Sites from the side "A"?. If I do port forwarding on the side B like: from side A :443 to side B : it works but only for one of the HTTPS sites.
I looked in to installing an Apache Server with SNI (server name indication) to do www.sideb.server1.com:443 and www.sideb.server2.com:443 to the only IP Address on side B and different servers, but don't know if I can "transfer" the traffic from that server to another one. Redirects, I assume, do not work because the client on side A cannot access other ports from side B.
It should be possible to let apache or ngnix work a a reverse proxy and forward the data to the right host based on the server name the clients sends using SNI. But, in this case all the certificates need to be located at side A, so that the reverse proxy can terminate the SSL connection with the correct certificate. And, client certificates will not work.
In theory there is another option: one could write a kind of proxy, which just looks at the initial SSL Client Hello (e.g the first packet sent from the client), extracts the clear-text server name extension and then forwards the whole connection to the right host. In this case you don't need to have the final certificates at the proxy side because you don't terminate the connection and client certificates will also work. Maybe someone has coded this already.
I have a question, I fear the answer.
I have:
a top level domain name (free from Tokelau, a territory of New Zealand, .tk, where else?),
a free 2 year ssl certificate from startSSL.com,
a free hosting package.
Now I jumped through every hoop startSSL wanted (admittedly wasn't too difficult), to get me my 2 year ssl certificate, and now I fear I have encountered a final barrier to success that might still stall my plans. I dreamt of a corner certificate stating "Secured by startSSL". I got the code snippet and everythings, and have pasted it into my website.
Problem. my host is not so keen on a free package to allow me to ssl.
As far as I know you need access to some config files to allow this to happen?
or can you just like with .htaccess and .htpassword files do the setting on your webhost?
Also you need a static IP. Are there any workarounds?
Or am I dreaming? Anyone with advice?
SSL Requires some files and configuration changes, pointing to the files.
Also, the static IP is required because with an encrypted request, there's no way to know to what host the request is intended without decryption. The use of a static IP address gives that request a destination.
To clarify: when using virtual hosts, multiple hosts will share the same IP address, so when a request comes in, the first two lines are:
GET /path/to/resource HTTP/1.1
Host: www.example.com
Apache (or any web server), looks at the 'Host' field to determine how to route the request. If the request is encrypted, there's no way to determine how to route the request, and you need to know what certificate to use in order to decrypt it.
Forget it. If your host doesn't have SSL configured, you have no chance to add it without their help
There are two problems with your proposed set-up.
Free hosts generally don't provide a control panel interface to allow installation of SSL Certificates (at least I've never seen it) as this requires either their help on the back-end or VPS / Dedicated Server access from the front-end.
Static IP address is a must for SSL certificate installation.
From webserver perspective, SSL cert is about a port and an IP address, even when being used with Name-based virtual hosts.
SSL is about the IP the matching the cert and domain in the URL/request(to verify the cert).
You would have to give a second SSL cert different port or different IP address on the webserver.
Alternatively, you can also get multi-domain and wildcard certs that allow different hostnames or domains to match the cert with different client request URLs, but the cert is still the only thing on that port/IP of the webserver.
Just my $.02