I've seen this question many times but all answers can't help me because I only rented server space and am not able to administer it.
I did the following:
I've bought a domain and ssl certificate from PositiveSSL
I've bought hosting space with a dedicated IP
I' only have cpanel with access to SSL/TLS Manager
I've created the CSR and everything and added and verified the certificate and got it.
I've then added it through SSL/TLS Manager and it should be working fine.
Now the problem:
When I try to open the website using https://www.mysite.com I get this error:
Secure Connection Failed
An error occurred during a connection to www.mysite.com.
SSL received a record that exceeded the maximum permissible length.
(Error code: ssl_error_rx_record_too_long)
What can I do in this case? My hosting provider has almost no idea about SSL and won't help me anymore :( so I only have access to cpanel and SSL/TLS Manager.
I've tried to reinstall it many times but the error stays.
SSl certificate will require a reserved IP on cpanel environment. As you have only access to your cpanel and not WHM, this mean you are on shared hosting environment. Which means your websites use the server shared/main IP.
solution: Ask your web-hoster to provide you with a dedicated IP for your domain with ssl
Technicaly, there is another solution, but they will say NO : Provide your web-hoster with the crt and ask him to install it trough WHM, they will have to reset the ssl vhost to nobody. This is where they will say NO!
when they will paste the crt content in the proper field to install your ssl, they wil click "fetch" this will load you private key and CA (if any) in the fields bellow. The most important are 2 fields just underneath the crt field: IP and user. In shared hosting CPANEL, each domain/website scripts will run under its correspondent user. Cpanel will not allow a user to run an ssl vhost on shared IP (cpanel is already using it for its own self signed certificate). The web_hosters need to know which user / is using how much ressources.
Cheers!
The error can be due to multiple reasons
a) The Port number for https connection is not open
b) The private key does not match with the public key
Related
I want to generate and install SSL certificate for a sub-domain.
The sub-domain is used with a different server (A record points to the IP) and it's where I want to add the certificate.
It's a shared hosting, with CPANEL, so it's easy to generate and install certificates, but I'm not sure how I should generate and install SSL with this setup, without going into the domain settings... if it's possible, any suggestions?
If not, please explain what should be done in such case..
This is Class 2 certificate as provided by letsencrypt? Only 2 requirements need be met:
DNS entry for specific address: sub.domain.xxx
... which points to a web server where you have access to the index directory.
tools like getssl https://github.com/srvrco/getssl then can obtain the certificate by putting down a key in s sub directory for validation.
If your cPanel installation is up to date you could request that cPanels AutoSSL be enabled. This would then automatically get a signed certificate approved by comodo and install it on any domains or sub domains that have it enabled on the server via the interface.
This question already has answers here:
Is it possible to have SSL certificate for IP address, not domain name? [closed]
(7 answers)
Closed 11 months ago.
I wonder why I am getting certificate error if I try to access a site with ip address instead of domain name. Lets say for example nslookup says google.com is 173.194.43.96, so I tried to browse https://173.194.43.96 and I got certificate error saying that the security certificate presented by this website was issued for a different website's address. Why is that so?
This is because an SSL certificate is issued for a particular domain name. If the certificate name doesn't match the visited domain, the browser will show an error.
One of the main functions of SSL is to prove to the user that they are really connecting to the site they requested, and not to an attacker masquerading as the end site. Without linking the domain name to the certificate this would not be possible.
It is conceivable that the browser certificate system could have been designed to include the IP address in the certificate, but this would make it difficult to use DNS load balancing or even to change hosting providers, as a new certificate would have to be issued each time this happened. If the certificate included just the IP address and not the domain, this would leave the user defenseless against DNS spoofing attacks. So the only way forward really was to use the domain alone.
As a matter of interest, it is possible to obtain an SSL certificate for an IP address - and as Google is their own certificate authority, they could issue themselves a certificate for 173.194.43.96 and thus make it possible to browse google securely by ip address, so long as they used SNI to serve up the correct certificate. It seems implausible that this would be worth the additional complexity however...
This is a nice introduction to SSL if you want to read more:
https://timnash.co.uk/guessing-ssl-questions/
On MAC High Sierra and Python 3.6.4, I tried the solution: requests toolbelt:HostHeaderSSLAdapter 1st, unfortunately, it doesn't work for me, then I tried
forcediphttpsadapter, got it works finally.
The author explains everything in the readme part and has provided a sample script and it can be followed easily.
1.Install the library by pip install requests[security] forcediphttpsadapter
2.run the sample script:
import requests
from forcediphttpsadapter.adapters import ForcedIPHTTPSAdapter
session = requests.Session()
session.mount("https://example.com", ForcedIPHTTPSAdapter(dest_ip='1.2.3.4'))
response = session.get(
'/some/path', headers={'Host': 'example.com'}, verify=False)
Note: For some cases, you may need to remove the prefix: 'www' from the url.
What happens is that the certificate is issued to www.google.com, and not to its IP address. Hence, your browser won't be able to verify the certificate, which lists www.google.com as entity.
For more info, see: www.digicert.com/ssl-support/certificate-name-mismatch-error.htm
The Common Name is typically composed of Host + Domain Name and will look like www.yoursite.com or yoursite.com. SSL Server Certificates are specific to the Common Name that they have been issued to at the Host level. The Common Name must be the same as the Web address you will be accessing when connecting to a secure site. For example, a SSL Server Certificate for the domain domain.com will receive a warning if accessing a site named www.domain.com or secure.domain.com, as www.domain.com and secure.domain.com are different from domain.com.
I am quite confused here:
I use DNSMadeeasy to manage my DNS. I have two apps.
One is Heroku hosted, and has https on https://example.com - Heroku has many great tutorials to setup the certificate, it hasn't been a problem.
The other one is a wordpress, hosted in 1and1 (though it shouldn't matter here), and is reachable at http://subdomain.example.com and we want it to be available at https://subdomain.example.com
1and1 does sell SSL certificate, but their automated setup works only when one uses their services for DNS also, as they say. Their support says it should be DNSMadeEasy which should be hosting our SSL certificate. I have the feeling it is not true, because for https://example.com, DNSMadeEasy was never involved.
Questions:
When does certificate querying occurs? Before, After, or in parallel of DNS resolution?
Who is hosting a certificate? The DNS provider? The server (accessible like a sitemap.xml at the root for instance)? A third party?
To enlarge the case, in general if I have a personal server with a fix IP, how can I communicate through https with a valid certificate?
In my case, how can I get my way out of it to make https://subdomain.example.com work?
You are right for not believing the 1and1 suggestion.
To answer your questions:
When does certificate querying occurs? Before, After, or in parallel
of DNS resolution?
A client resolves domain name to an IP address first. So DNS resolution happens first.
Who is hosting a certificate?
The server (in simplistic terms) hosts the certificate.
When a client wants to connect to your site (via HTTPS) it will first establish a secure connection with that IP address on port 443 (this is why usually (without SNI) you can only have one SSL certificate per IP address). As part of this process (which is called handshake) a client can also specify a server name (so-called server name extension) - this is a domain name of your site. This is useful if you have an SSL certificate that is valid for multiple domains.
A good/detailed explanation how it works can be found here
http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html
if I have a personal server with a fix IP, how can I communicate
through https with a valid certificate?
Your server will need to be able to respond on port 443 and have/host an SSL certificate for a domain that resolves to that IP address.
In my case, how can I get my way out of it to make
https://subdomain.example.com work?
You need to purchase a certificate for subdomain.example.com and install it on the wordpress server.
Usually in hosted solution like yours you have 2 options:
Buy the SSL certificate via the provider (1and1 in your case) - a simpler option, they will configure everything for you.
Buy the SSL certificate yourself. Here you will most likely need to login to your 1and1/Wordpress management interface and generate a CSR (essentially a certificate request). Then you purchase the SSL certificate using this CSR and then you can install it via the same management interface.
The process will look similar to this:
http://wpengine.com/support/add-ssl-site/
This problem is driving me mad but hopefully to you people it may be simple.
This is what I have done:-
Created a new (self-signed) SSL certificate in Plesk 12 to secure the panel.
Set it to use this as the panel certificate.
Changed the ip address to use this new certificate in Tools/IP Addresses
I have checked the sites ssl certificate on numerous online checkers and they all report the certificate is fine (although it being self-signed).
But whenever I browse to the panel I still get 'Your connection is not private'
The trouble is then that the PEM encoded chain, which I believe to be the certificate it's using, is not the self-signed certificate I created. Then after a certain period of time, approx 5 mins, even when I'm still using the admin it will go to 'Your connection is not private' again and show a different PEM encoded chain.
Please could someone help as this drives me crazy when I'm using Plesk.
The sever is running CentOS 6.6 and the servers default address is sris1.co.uk
Thanks in advance.
Most probably, you are accessing both https://sris1.co.uk and https://www.sris1.co.uk, while certificate is issues for www. domain, and it's understandably failing when you access just sris1.co.uk, and browser thinks, that you are being tricked, since cert is issued for different site.
I've never met such problems in Plesk, so, this is only thing, that I can guess from provided information.
We allow users to dial-in to our system.
We run a firewall on the dial-in system that blocks all access by default and we only allow certain servers to be accessed by adding specific rules.
We have a web service that contacts our server. The service calls are made over SSL.
The SSL Cert is from GoDaddy.
We have found that when connecting to the service the first time something tries to verify the SSL certificate. We are seeing dropped packets to Microsoft IP addresses via port 80.
If we allow access to the Microsoft IP, the software works perfect.
Issue being the IP is random, so I have been adding a few different IP hosts.
Looks like some type of SSL verification system or something... anyone ever run into something like this? or know of a block of IP's or hostnames that I can allow in the firewall?
It's most likely trying to contact the Certificate Authority (CA) to verify the SSL cert.
It smells like browser is trying to connect to a CRL server. Try to reverse-resolve the IP addresses to a domain name and you should get some clue.