I have 2 domains (domain1.example and domain2.example) under the same Ubuntu 14.04 Apache server. Each domain has one SSL certificate.
It happens that, sometimes, when users open domain2.example on the browser, they receive the domain1.example SSL certificate instead of domain2.example certificate. The weird thing is that it happens sometimes, and also, that if I change the *:443 default server, it starts answering the SSL of the new *:443 default server.
What do you think is happening? I cannot find the error.
Related
I've purchased a TLS certificate from godaddy for a domain (say somebeta.com - actual is different). The DNS points to an AWS EC2 Linux server which I operate. The httpd web server on this EC2 serves the REST API requests.
I've installed the certificate on the AWS EC2 server which points to beta.com, and at no place in httpd.conf or ssl.conf have I specified the ServerName directive. Every thing works nicely, https://somebeta.com works, green color appears, all is good.
Now I create a new subdomain routing on godaddy DNS, by pointing alpha.something.beta to another EC2 instance. When I install this certificate on another EC2 server, I get following in ssl_error_logs:
ip-<Some IP>.ap-south-1.compute.internal:443:0 server certificate does NOT include an ID which matches the server name
I looked on SO, and found that the hostname of the machine should match the CN in the certificate. If it does not, then SSL/TLS would fail (I believe mod_ssl checks and fails this).
My question is, I've not set the hostname of the actual somebeta.com EC2 server, but still the SSL/TLS works great. How is it happening? Does mod_ssl do some intelligence to figure that the localhost is actually pointing to somebeta.com (by doing DNS/etc) and that's why it works?
Please don't close the question too early, I understand the working of SSL/TLS in its entirety, I just need to know how the thing is being validated by mod_ssl in httpd. Does the absence or presence of ServerName directive matter always, or only sometimes?
I have a website setup, if I load the website with http://www.url.com:443 it works as expected, but if I load https://www.url.com I get a "ERR_CONNECTION_CLOSED" error on Chrome.
I have setup iptables to load port 3000 through both port 80 and 443.
Server is running centos, there is no ssl certificate setup at this stage
You configured the server to listen on port 443 but didn't configure it for SSL traffic. In other words, you merely changed the port from 80 to 443, so it is serving HTTP on port 443.
You say there are no SSL certificates set up. That's the problem. You need to set up certificates (even if only self-signed ones) for HTTPS to work at all. It's the key and certificates from this setup process that tell the server how to encrypt the HTTPS data, and how to identify itself.
This page will help you to set things up properly: https://wiki.centos.org/HowTos/Https
There are many places you can look for advice on creating keys and certs, but the easiest and least expensive options are StartSSL and LetsEncrypt. Both will do this for you at no cost.
https://letsencrypt.org/
https://www.startssl.com/
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 have successfully added SSL certificate to my url. now url is "https://puinex5xgm-l1". Its working fine on browser. but whenever I try to add port to this ulr "https://puinex5xgm-l1:90/" its giving me "SSL connection error ERR_SSL_PROTOCOL_ERROR". My apache server is running on port 90.
While creating certificate I have used domain name as "puinex5xgm-l1".
Please help.
ERR_SSL_PROTOCOL_ERROR is not related to the certificate. My guess is that you don't have https on port 90 enabled but instead plain http, which then will cause such an error.
I have found the solution.
I have made changes in "httpd-ssl.conf" file. Here, I have used "VirtualHost default:90" instead of "VirtualHost default:443".
Now Apache server listening my port.
Its working fine now.
after enabling SSL Certificate IIS7.5 does not start Default site and above error occurred.
Probably you are configuring your host headers incorrectly. For SSL to work properly you need to actually define the domain name it will use, or bind the site to *443 which means all ssl requests on that particular ip would hit that site. Try doing a full restart, and if that doesnt work try and see if something is grabbing your SSL port.