I have successfully created a Let's Encrypt SSL certificate using Lone-Coder's Windows Sample
The SSL certificate has been installed and appears in IIS under Server Certificates.
A HTTPS binding was successfully associated with my site in IIS.
The StaticFile handler mapping is being executed before the ExtensionLess URL Mapper.
When I visit my domain: https://subdomain1.mysite.com I am getting a site not found.
Further information:
I have three sites on this server:
subdomain1.mysite.com (this one has the Let's Encrypt SSL applied)
subdomain2.mysite.com
www.mysite.com
Try deleting and manually adding the binding again. Sometimes it can get miss configured.
Check firewalls.
Related
1) http and no-dns (working)
I was using nifi on http, and it was working fine. at that time I was accessing it via ip or server name itself. everything was working fine.
2) https (self signed) and no-dns (working)
i did https setup using toolkit and it worked, although chrome kept showing red color message. which was expected. but atleast things worked.
3) dns (internal) + signed certificate (external authority (Symantec))
dns works fine, as I am able to ping the box using dns. also i added this dns to etc host file.
even though nifi is internal to org, I still went head and bought a certificate. and CNAME i used was the dns name of my server.
certificate i got was a chained certificate
my_dns_>TrustedSecureCertificateAuthority5>USERTrustRSAAddTrustCA>AddTrustExternalCARoot
I create a JKS, and added all of them in it, also added a key_pair to JKS, and I appended all certificated to key_pair too.
Then I changed nifi.properties and used same jks as trust-store and key-store.
now if i use nifi with new dns and https, i am getting "ERR_SSL_VERSION_OR_CIPHER_MISMATCH" (attached image) on Chrome. On IE, i get a TLS error. so I dont think thr is something wrong either with certificate or browser.
if I give url as (see image) https://server_name:9447/nifi, nifi opens up..with but still shows up red color warning, but this time is not for self signed certificate, but for name not matching. which confirms that nifi web server has access to my new jks, and it also reads it...but then why it is not working?
what am i missing here? can nifi run on externally bought certificate? or it always has to work with self-signed certificate?
if you are running nifi with external certified certificate, please share your configuration.
do I still have to use toolkit? or toolkit does same thing, which i did by buying the certificate? if true, what am i missing here?
so here is how i resolved it.
after nothing worked. I went back to https setup of nifi, where nifi generates keystore and truststore jks.
and then i downloaded both, and edited it. I removed all previous certificates (self signed one). and then added my CA certificate chain.
then simply uploaded them back. then just restarted nifi.
nifi is now on https.
I have a win 7 x64 box I recently reimaged and I have installed IIS7.5 and PHP 7. I am trying to set up localhost sites for secure https and I have successfully created a self-signed certificate for this purpose. I have set the IIS bindings for the site to use https over port 443 (IP Address: All unassigned) and selected the new SS cert.
When I go to https://localhost/php_info.php on my computer, I can see the phpInfo content but Chrome displays alerts that site is not secure.
Certificate error: There are issues with the site's certificate chain (net::ERR_CERT_COMMON_NAME_INVALID).
Obsolete connection settings: The connection to this site uses a strong protocol (TLS 1.2), a strong key exchange (ECDHE_RSA with P-256), and an obsolete cipher (AES_256_CBC with HMAC-SHA1).
What can I do to run secure sites over localhost?
The certificate error can be fixed if you generate another certificate, with Subject Alternative Name (which is required by Chrome). More information can be found in,
https://blog.lextudio.com/why-chrome-says-iis-express-https-is-not-secure-and-how-to-resolve-that-d906a183f0
The TLS cipher should be cleaned up by using a tool such as IIS Crypt,
https://www.nartac.com/Products/IISCrypto
Jexus Manager has SSL Diagnostics, which can provide you hints on what's wrong in your server configuration,
https://www.jexusmanager.com/en/latest/tutorials/ssl-diagnostics.html
I followed all the instructions to get a SSL certificate from Let's Encrypt for my website, but two hours after I successfully got the message "Your certificate and chain have been saved", I still cannot access my website with HTTPS and get the error "the website refused the connection".
Do you know how much time is needed to activate the certificate?
On the web hosting offer of OVH, the HTTPS protocol is available after the deployment on all the load balancing infrastructure. It take around two hours.
You can check your "multisite". Maybe your website doesn't have the "SSL" flag enabled and the generated certificate do not handle your website.
I easily installed an SSL certificate the first time through, but I am unable to get it to renew.
I scheduled the terminal command to automatically renew the certificate each month, but it is responding with an error. I also get the same response when running it manually.
Terminal Command
curl -X POST https://forge.laravel.com/api/servers/<serverNumber>/sites/<siteNumber>/ssl/renew?api_token=<my-token>
Response
Cloning into 'letsencrypt1462928414'...
nginx stop/waiting
nginx start/running, process 10734
# INFO: Using main config file /root/letsencrypt1462928414/config.sh
+ Generating account key...
+ Registering account key with letsencrypt...
Processing donniebrandt.com with alternative names: www.donniebrandt.com
+ Signing domains...
+ Creating new directory /root/letsencrypt1462928414/certs/donniebrandt.com ...
+ Generating private key...
+ Generating signing request...
+ Requesting challenge for donniebrandt.com...
+ Requesting challenge for www.donniebrandt.com...
+ Responding to challenge for donniebrandt.com...
ERROR: Challenge is invalid! (returned: invalid) (result: {"type":"http-01","status":"invalid","error":{"type":"urn:acme:error:unauthorized","detail":"Invalid response from http://donniebrandt.com/.well-known/acme-challenge/JdG5PtzEcqZMMDVhx2VNN5Wmvldwtl84B6q3j1AQcP0 [104.18.50.184]: 526"},"uri":"https://acme-v01.api.letsencrypt.org/acme/challenge/S6oIx5ZFyzu80fkpjoCcAgVDp7p8aLo6UGLLt7flP-g/81801388","token":"JdG5PtzEcqZMMDVhx2VNN5Wmvldwtl84B6q3j1AQcP0","keyAuthorization":"JdG5PtzEcqZMMDVhx2VNN5Wmvldwtl84B6q3j1AQcP0.0N_sDHF2rXqfyPHGi4ZmXDAkrmwbMJ-S_ZghYPtSN2g","validationRecord":[{"url":"http://donniebrandt.com/.well-known/acme-challenge/JdG5PtzEcqZMMDVhx2VNN5Wmvldwtl84B6q3j1AQcP0","hostname":"donniebrandt.com","port":"80","addressesResolved":["104.18.50.184","104.18.51.184"],"addressUsed":"104.18.50.184"},{"url":"https://donniebrandt.com/.well-known/acme-challenge/JdG5PtzEcqZMMDVhx2VNN5Wmvldwtl84B6q3j1AQcP0","hostname":"donniebrandt.com","port":"443","addressesResolved":["104.18.50.184","104.18.51.184"],"addressUsed":"104.18.50.184"}]})
I also verified that the .well-known/acme-challenge directory exists, but it doesn't change the error.
The error message shows your website is offline for one of the domains:
ERROR: [...]"Invalid response from http://donniebrandt.com/[...]526"},[...]
Try access http://donniebrandt.com and you will get error 526 (invalid SSL certificate).
As cloudfare states:
The HTTP Error Response Code 526 occurs when CloudFlare is unable to successfully validate the SSL certificate on the origin web server and the CloudFlare SSL configuration on the website is set to "Full SSL (Strict)".
In other words, the CDN you´ve setup in front of your server tries to reach your server through HTTPS, however your SSL certificate is invalid (maybe expiered or root CA not trusted by Cloudfare CDN). So Cloudfare will not fetch content from your server.
I am not familiar with Cloudfare but you can do one of the following:
disable temporally strict SSL in cloudfare until you renew your certificate and, next time, renew before it expires so there is no need to disable it again.
temporally redirect your DNS direct to you server instead of CDN, renew certificate and redirect it again. The downside here is that DNS propagation might take sometime and you will loose benefit of CDN for a long period depending on DNS setup.
Since you said you got SSL working first time I am assuming Cloudfare trusts LetsEncrypt (or it would not work for the first time). However worth check it.
It's not really a fix, but I skirted the issue by recreating the site in Forge and reinstalling an SSL.
This should no longer be an issue since Forge now handles SSLs better.
Forge will now automatically renew LetsEncrypt certificates for you
every week. You no longer need to manually add a scheduled job to
perform the renewal. To generate an auto-renewing LetsEncrypt
certificate, simply obtain and activate a new certificate using the
form above.
Attempting to implement client authentication with an SSL cert, according to this HOWTO,
I receive the following errors.
Apache:
Re-negotiation handshake failed: Not accepted by client!?
Firefox:
ssl_error_handshake_failure_alert
I assume it is a configuration error, but have not been able to locate it.
Additional info:
Commercial CA server cert servers secure works without problem in Apache 2.2 & Passenger.
Only client authentication related directives do not work.
Is your certificate signed by verizon or someone like that? If not, you might want to add an exception in firefox. By default it stops you.
pd. doesn't sound like a passenger question
When you require client certificate authorization, you have to point Apache to file containing the root CA (and intermediates also) certificates which issued the client certificate
Also post your client authentication config part.