according to this question all HTTP header when we are using HTTPS are encrypted(including request URI and Host header).
when browser want to browse a page on website that using HTTPS, it first create secure connection, then it sends HTTP request(encrypted) and server return the answer to browser. Now assume there are more than one secure website with more than one SSL certificate, so when server want to create secure connection how does it detect which certificate should be used because it doesn't know anything about request!!!
Since the SSL channel is negotiated prior to the reception of the Host header, an HTTPS server can use at most one certificate per bound IP endpoint (IP address and port). In other words, to use two different SSL certificates, you will either need to bind each virtual host to a different port, or a different IP address.
Before TLS the server indeed didn't have a way to know certificate of which host it should present to the client and this caused problems.
In TLS there was a special extension named Server Name introduced (see RFC 3546), which lets the client tell the server, what host the client wants to connect to. Based on contents of this extension the server can present proper certificate. Of course, all of this requires that TLS and the extension itself are supported and used by both parties.
The basis of this is to provide a SSL key(set) for each virtual server.
In Apache, for example, it's relatively simple. Each shared site is likely in a <VirtualHost> directive. The SSL keys can be specified within that, and thus apply to that virtual host only.
Rough example:
<VirtualHost *:443>
ServerName server.com
SSLEngine on
SSLCertificateKeyFile /etc/ssl/server_com.key
SSLCertificateFile /etc/ssl/server_com.crt
SSLCertificateChainFile /etc/ssl/server_com.ca-bundle
The server will then use the specified keys for all requests directed to that site over HTTPS. Further details on the Apache site. Similar things should apply to most web servers that support a concept of virtual hosts.
You won't get any errors, as the certificate and domain name match up.
Related
I have trouble installing the ssl certificate in a server.
The vhost file looks like this
`<VirtualHost <ip>:443>
DocumentRoot /var/www/html2
ServerName www.yourdomain.com
SSLEngine on
SSLCertificateFile /path/to/your_domain_name.crt
SSLCertificateKeyFile /path/to/your_private.key
SSLCertificateChainFile /path/to/YourIntermediateCertificate.crt
</VirtualHost>`
I have tried SSL checker and the results are as follwing.
the error it shows is
The certificate is not trusted in all web browsers. You may need to
install an Intermediate/chain certificate to link it to a trusted root
certificate. Learn more about this error. The fastest way to fix this
problem is to contact your SSL provider.
An intermediate certificate is already installed. The common name for server in the image should be same as host name. I am not sure why it is "CloudFlare Origin Certificate". Need help in solving this issue. Thanks!!
I have researched and found an answer for this issue.
To resolve the issue we need to enable the proxy for all A, AAAA, and CNAME records using cloudflare dashboard. Below is the explanation for why to enable the proxy.
Normally, the request hit the origin(server) directly and response is served. To encrypt this communication we use SSL certificate. But, the SSL certificate is also used for the identity of the origin server. Here in the above case, no chain certificate file is provided to identify the origin server i.e yourdomain.com, rather the certificate is issued to cloudflare.
After enabling the proxy, the request hits cloudflare and the same request is sent to the origin server, the response from origin server is received by the cloudflare proxy and it is sent to the user. In this way the users browser thinks cloudflare proxy as the origin server and identifies cloudflare since it has its own ssl ( we don't need to bother ).
After enabling proxy, we don't need any chain certificate file to be installed in the origin server. We just need to install the server certificate issued by cloudflare.
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 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 host 2 sites on a single IP address and they need to be accessed via SSL however the majority of my users use Internet Explorer on Windows XP meaning using multiple SSLs with SNI may prevent them getting access.
I was wondering if I could use a multiple virtual hosts but still use a single SSL certificate and avoid SNI ?
Alternatively how feasible is it for me to install two Apache webserver instances, each its own DocumentRoot and own SSL certificate and for me to simply use the first Apache webserver as an entry point to entertain some requests and to redirect others to the other SSLed Apache instance ?
Could I potentially use the Windows Host file (Windows 2008 Server) to redirect incoming requests to the intended Apache Server instead of using VirtualHosts ?
Apologies if I have confused concepts.
You can try to purchase an X.509 certificate with two domains in it. I don't know what particular CAs do this, but I also don't see why they would refuse. You need to ask their support, though.
Your idea to redirect some requests to another server residing on a different port sounds good as well, though you will have to use two different certificates for different domain names, of course.
Finally if your second domain can be something like additional.mydomain.com , you have greater chance to buy a certificate issued for mydomain.com + www.mydomain.com + additional.mydomain.com (this can be a wildcard certificate or a certificate with additional subdomain names).
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