I know importing the certificate into browser trust store can dismiss the warning, but is it the only workaround? Is it possible using a domain (with a valid SSL) to reverse proxy the localhost web server: redirecting user's request to the localhost?
If you have an external domain and a valid certificate for it (i.e. both certificate and key) you could configure your localhost server to serve this domain and use this certificate. To make sure that any local requests to this domain actually reach your local server instead of the external IP you need the appropriate name resolution though. This can be done for example by modifying the hosts file (i.e. /etc/hosts on UNIX, c:\Windows\System32\Drivers\etc\hosts on Windows).
In other words:
Configure the local web server to expect requests for example.com instead of localhost, i.e. set certificate and key you have for example.com and configure the expected name to example.com.
Modify the local hosts file to resolve example.com with 127.0.0.1.
Access the local web server with the local browser by using the URL https://example.com. Due to the changed local hosts file it will use 127.0.0.1 as the IP address for example.com and thus access the local web server. This will provide the publicly trusted certificate for example.com so that the browser will not complain (issuer CA is trusted and subject of certificate matches the URL).
Remember to change your local hosts file back if you want to access the real (external) example.com.
Related
Let's say I edit my hosts file on my computer to make google.com point to my VPS server IP, and the server has virtual host/server block for google.com configured trough Apache or Nginx.
So when I visit google.com it'll load whatever is configured on the server through HTTP, how can I make it HTTPS? can I do it with Let's Encrypt? I have tried to edit the hosts file on the VPS itself and then run cert-bot, but that didn't work.
in simple words: I don't own the domain, but would like to own it on my machine only trough https.
I don't own the domain, but would like to own it on my machine only trough https.
You can't do it with a publicly trusted certificate. You can create your own PKI with your own trusted root CA which you import as trusted in your own browser. Then you can create the server certificates you want with this CA and since your browser trusts this CA it will also accept your own certificates.
There are many resources online which describe how to create your own CA, like here or here or here.
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?
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.
I am trying to configure a remote server to host two or more development sites. My current approach was:
Hostname: somedev.something.somethingelse.com
Desired site 1: dev1.somedev.something.somethingelse.com
Desired site 2: dev2.somedev.something.somethingelse.com
I modified my hosts file so that:
dev1 127.0.0.1
dev2 127.0.0.1
I created a wildcard SSL certificate for my domain, and configured the bindings to use that SSL certificate.
However, while on the box locally I can access my sites at the desired sites, how can I expose this such that I can browse remotely?
You will either need to use a public DNS server to point those DNS names to the server's public IP address, configure your existing DNS server to point those names to the IPs (if you have a DNS server), or modify the hosts file on the machines you want to access it to point those names to the server's IP address