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.
Related
Pulling my hair out here. Yesterday I set up an SSL Certificate in IIS10. This is the process I followed:
In IIS, under Server Certificates complete Create Certificate Request (generated server.csr & server.key)
Go to sslforfree.com and start "create certificate" process.
Enter Static IP in Domain box
In Validity, choose paste Existing CSR (paste in contents of server.csr)
Select free 90 day certificate
Choose HTTP file upload and add auth file to virtual share in IIS.
Verified OK.
Download certificate
Back in IIS, select "Complete Certificate Request"
Browse to and select "certificate.crt" file.
Give it a friendly name etc, and save.
Browse to website under sites in IIS, and select Bindings. Choose the IP of the server, the incoming Port, and the newly imported SSL certificate.
Back in sslforfree, check the installation.
Everything all good
So everything was working beautifully, could see the certificate in the browser etc, job done.
Now come to today, and the server is actively refusing requests. Go back to check the installation of my SSL on sslforfree, and it's no longer found. Tried removing and re-adding, but nothing I do seems to get the SSL to be visible.
It's not that the certificate is refused, the browser doesn't even think it's there. Why would IIS suddenly stop sharing the certificate? I am totally stumped.
EDIT
As per the advice below, I set up a DNS name with CloudFlare and pointed it at my server.
I Set up the bindings in IIS to link to the new hostname and removed the old certificate (one for port 443 and this one for port 4443 which the API runs on):
Ports 80, 443 and 4443 are all port-forwarded on the router to my server:
I then downloaded Win-ACME and successfully created the Let's Encrypt certificate, and the renewal task created in Task Scheduler.
SSL Cert now shows in Bindings:
SSL Certificate appears to be all good:
...but when I go to the site, using the new domain name. Same problem... no certificate:
So I'm not sure what the problem is here...
This issue may happens when the imported cert does not have a private key associated. solution would be to import the .CER file to your system(from where certificate is requested) personel store and export it with private key. Then copy the .pfx file to required server and import it from server certificate option under IIS.
And you can refer to this link: The Whole Story of "Server Certificate Disappears in IIS 7/7.5/8/8.5/10.0 After Installing It! Why!".
Thanks to Lex Li, I was able to dig around with Jexus Manager, and IIS Crypto to work out what was wrong.
Seems having TLS 1.2 an TLS 1.3 enabled on my machine at the same time was causing issues. Discovered this using Postman and disabling certain TLS Protocols, eventually getting it to work.
For those of you who may experience similar issues, using this application and setting it to "Best Practices" after disabling TLS 1.3 in my Registry, I finally have it working, with a certificate.
Previously I used RapidSSL certificate. After it expired I moved to Lets Encrypt (free ssl) and installed on my server. But site uses still old SQL certificate after couple of refreshes taking new SSL certificate and resources (css, images, scripts) are not loading gives NET::ERR_CERT_DATE_INVALID error.
I restarted Apache couple of times.
I'm using Ubuntu 16.04.
NET::ERR_CERT_DATE_INVALID means your SSL certificate date is invalid, that is because your old certificate has expired. Check your apache config to make sure that - certificate files mentioned are the desired ones. For detail debugging of your problem, you need to look at your apache server log could be located at /var/log/apache2.
I have my website https://www.MyWebSite.com running on port 433. But I also have a admin login that only are available from the office local network http://MyServer:9999/Login.aspx. Both addresses points to the same site but different bindings.
Is it possible to get the one on port 9999 to use https? I tried creating a self signed certificate in IIS but my browser still complained, even though I exported the certificate and stored it in my CA Trusted root.
So just to sum everything:
My regular site: https://MyWebSite.com <-- working fine
My admin login, only accessible via local network: http://MyServer:9999/Login.aspx works fine.
When adding a selfsigned certificate issued to "MyServer" (not MyWebSite) and add the new binding on port 9999 I though to the website but Chrome is giving me a warning NET::ERR_CERT_COMMON_NAME_INVALID, even though the cert is Issued To MyServer and are trusted
Is it possible to get the one on port 9999 to use https?
yes it is possible to setup another port with selfsigned
certificate.
Normally Selfsigned certificate will have fully qualified machine name
e.g. machinename.subdomain.domain so you have to browse using https://machinename.subdomain.domain:9999/
Please double check what error you are running into ,In chrome
Your connection is not private
Attackers might be trying to steal your information from in08706523d (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID
in IE,you may get
There is a problem with this website’s security certificate.
The security certificate presented by this website was issued for a different website's address.
Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.
In that case,assuming you have given hostname as * in IIS binding, and also installed the selfsigned certificate installed your "Root Certification Authorities " You should be able to browse to
https://machinename.subdomain.domain:9999/ without any issues
I have a website with two different certificates. One for official use so the user doesn't see a self-signed alert. And one for internal use for private subdomains (for phpmyadmin, roundcube and so on). These subdomains are only for admin use, so it seems useless to me to spend money on a wildward-certificate. Therefor the wildcard-Certifitae is Self-Signed and I have memorized the hash.
Also I got an etherpad-Installation on that server on a different port than http (not a difefrent subdomain). Etherpad now seems to send this header "Strict-Transport-Security: max-age=31536000; includeSubDomains" which is just dumb, because i couldn't find an option to turn off the "includeSubDomains".
Now when I was in my pad and then try to use my admin-Subdomains I get an Error because of HSTS, without the option to set an exception and therefor these are now unusable for me.
Does somebody has an idea how I can get rid of the "includeSubDomains" in the etherpad installation?
I would be glad if someone could help me. Thank you.
It's a tad old, but I would like to point out the better alternative: install the certificate of the (self-signed) CA that you used to sign you own certificate as a trusted CA in your browser.
I just share the CA certificate on my webserver, and download/install it using the IP-address to avoid the HTST-trigger. You can point your browser to
http://1.2.3.4/my_certificate.pem
and your browser will ask you for what you want to use that certificate. If you set it to be allowed to sign websites, and the CN in your certificate matches the hostname your using it for (roundcube, phpmyadmin, etc), your browser will happily accept your self-signed certificates, even when HSTS is enabled.
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