When having multiple domain names point to the same server. But you only have a certificate for one of these domains, is it possible to block the other domains in Apache. But only when HTTPS is used not when HTTP is used.
I tried using a NameVirtualHost setup for 443 port. But when the domain is not found Apache simply defaults to the first virtual host. I would like it to refuse the connection. In this way when connecting directly through HTTPS on one of the not supported domains the connection is refused rather then having the browser display warning screen because of a wrong identity.
Any thoughts?
Not possible.
This is a chicken and egg problem - to verify an https connection the browser connects and tries to validate the certificate/common name and the given URL. The first handshake / connection to port 443 has to be encrypted.
The only way to handle this problem would be to setup dedicated IPs for all domains - or for at least the domain using HTTPS.
It's far from ideal, but another option would be to use a non-standard for your HTTPS site and not have the server listening on port 443.
Related
I have a HTTPS website hosted by IIS. In this site I embed another HTPPS website within a iframe. The content of this iframe is hosted by Apache. Both servers, IIS and Apache, are on the same server.
Do we need to have the same SSL certificates on both webservers?
The first listens on port 8443 and the second one on port 443. Do we need to separate public IPs? Is there another way to root internally?
How would be the proper setup having two different webservers (IIS, embeded Apache) and only one external IP?
Do we need to have the same SSL certificates on both webservers?
No, you could bind different SSL certifcate if you bind different domain for your IIS or apache server.
The first listens on port 8443 and the second one on port 443. Do we need to separate public IPs? Is there another way to root internally?
No, we access the site by using the same ip with different ports.
How would be the proper setup having two different webservers (IIS, embeded Apache) and only one external IP?
In my opinion, the only things is that you should make sure the port is free for each web server.
For example, if IIS use 80, the Apache couldn't use 80.
I have a wildcard SSL certificate on my apache server. It works perfectly with my domain, but the mistake is that it works with all the domains on my apache server ! And I don't want it, when I go on https://www.mywebsitewithouthttps.com, firefox tell me that the page is not secure because the certificate is for www.mydomainwithhttps.com. If I add an exception for this SSL error on my browser, it is not "mywebsitewithouthttps.com" that is display but "mydomainwithhttps.com" (on this URL : https://www.mywebsitewithouthttps.com) !
I don't want my certificate to work for all the other domains ! It's a big problem because Google is crawling and indexing all my other domains on HTTPS with the content of mydomainwithhttps.com :-(
This my virtualhost for SSL :
NameVirtualHost *:443
<VirtualHost *:443>
ServerName www.mydomainwithhttps.com
DocumentRoot "/home/mydomainwithhttps/www"
suPHP_Engine On
suPHP_AddHandler x-httpd-php
suPHP_UserGroup mydomainwithhttps users
AddHandler x-httpd-php .php
SSLEngine on
SSLCertificateFile /certificates/ssl_certificate.crt
SSLCertificateKeyFile /certificates/www.mydomainwithhttps.com.key
SSLCACertificateFile /certificates/IntermediateCA.crt
</VirtualHost>
If you make a HTTPS request the client will establish a TCP connection to the relevant IP and port (usually 443) at the server. If the connection succeeded it will start the TLS handshake and during the TLS handshake it will get the certificate for validation.
If you have multiple servers at the same IP address and port they all share the same TCP listener. Since the TCP connection attempt has no information about the targets server name but only has the targets IP address and port the listener will accept all connection attempts, even if the (yet unknown) target hostname has no HTTPS configured.
Modern clients then send the target hostname inside the TLS handshake and only then the server knows what the client wants. If it has HTTPS configured for the requested name the server can send the appropriate certificate. If HTTPS is not configured for this name the server will either send a default certificate or close the connection (maybe send a TLS alert when closing).
In summary this leaves you with the following options:
Use a different IP address for HTTPS sites and non-HTTPS sites. This way the TCP connection will already fail because the server is not listening for connections on this IP:port.
Configure your server to return an error when the client requests a hostname for which no HTTPS is configured. This way the client will probably get some strange error message about HTTPS problem in the browser. I'm not sure but maybe you can setup Apache this way when using the SSLStrictSNIVHostCheck on option. If this option does not help then apache might not support this kind of setup.
Configure your server to use a default certificate (usually the first configured certificate) whenever the name does not match or the client does not support SNI. The client will get a certificate mismatch warning in the browser. This is the setup you currently have.
Setup HTTPS properly for all domains either by having separate certificates or by including them all into a single certificate.
Thus to make sure that the bots don't assume that your site can do HTTPS you need to go with option 1 or 2. Please note also that in all of these cases you expect the bots to support SNI, which not all do. Therefore for best compatibility you would need to use a separate IP address for each HTTPS site.
You can configure the multi domain with SSL and with different certificate on both UBUNTU and RHEL by following multi donain with ssl
The problem is that Apache will try to find config for https://www.mywebsitewithouthttps.com/ and when it doesn't, it will default back to the first https config (the one for mydomainwithhttps).
This will show a cert error but, as you've experienced, if you click through, you see the wrong site.
I cannot however understand Google crawling and indexing the site. I would have thought it would have stopped when it saw the cert error? I'd be very surprised if that is not the case but if it's not you can put a rewrite rule on for those hostname a to redirect back to http.
There's only 2 ways around this:
Get certs for the other domains so you can connect via https. You can still redirect back to http if you really want.
Separate out the servers with https to a different server (or a different IP on the same server and set up Apache config to listen on port 443 on https IP address only).
That's just the way Apache (and most - if not all - other webservers) work.
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.
is there a way to solve this:
there is a domain example.com, on port 80 it redirects to 443 so it's always SSL connection and it passes to uwsgi via nginx. Now sockets run via a node connection on example.com:3000.
Is there an easy way to have that example.com:3000 run as SSL? The reason why is that Chrome gives a warning that the site includes resources that are not SSL.
I created another server in nginx, with the same domain listener but for different ports and passed the info through to node, and made that port SSL.