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.
Related
I have a Service which is running in Istio 1.16 with envoy sidecar injection enabled.
The service connect with a remote API every now and then to send the health information.
The remote end point is https but without having a domain name, yeah the endpoint have to be invoked like https://168.x.x.x/http/health. I could see the connection is working fine with another API but with a proper hostname.
So the issue is clearly with the DNS resolution, I am not great with networking. So, you folks should help me out.
This is the error i get from the server (of service).
x509: cannot validate certificate for because it doesn't contain any IP SANs
Istio version - 1.16
Kubernetes - 1.24
golang (service) - 1.19
Can we bypass this x509 SAN check using destination Rules?
The error "x509: certificate has expired or is not yet valid" usually occurs when the SSL certificate being used has expired or has not yet been activated. This error can also occur when the certificate being used is not valid for the domain or IP address that the request is being sent to.
To resolve this issue, you will need to either obtain a new valid SSL certificate or renew the existing certificate.
You can check your certificate expiration date by using the below command:
kubeadm certs check-expiration
Refer to this SO for more detailed steps.
Please suggest on the issue which we are facing while accessing SSRS Secured web services and web portal URL Error Message
"Your connection is not private Attackers might be trying to steal
your information from <> (for example, passwords, messages, or credit
cards). Learn more NET::ERR_CERT_REVOKED"
We have got the SSL certificate reinstalled and restarted the SSRS services , but still no luck .
Could anyone please guide us in this regard Server configuration details are as follows -
-Microsoft SQL Server Version 17
-SSRS product version of 14.0.600.490
-WINDOWS SERVER 2016 DATACENTER
The SSL certificate is configured on Windows server .Also the SSL is configured in Web services and Web portal SSL configuration in SSRS is with (ALL IPV4) and (ALL IPV6),SSL certificate and validity till 2019
There was a patch update last week and post that we are unable to access secured urls
https://<>/reports/
https://<>/reportserver/
but we can access non secured urls
http://<>/reports/
http://<>/reportserver/
If the site is publicly accessible, please check the certificate served by your web server via SSL Checker.
Compare the certificate serial number and expiration date with the data of the certificate you installed in your web server or hosting control panel. In many cases, I saw that the server uses an old or invalid certificate.
(Source)
If you are sure that the correct certificate is served, clear the CRL and OCSP cache:
certutil -urlcache CRL delete
certutil -urlcache OCSP delete
You can also try disabling certificate revocation in browsers. It fixes ERR_CERT_REVOKED on the client side.
So I have made a small script on my website for my telegram bot. Only problem is that if I set my URL as webhook for the bot it gives an SSL error.
Also tried to add an self signed certificate, so has_custom_certificate turned to true, but the same error appeared.
What am I doing wrong?
You have to create a self-signed certificate for deploying your server over https. If you are using flask you can follow this nice tutorial - https://blog.miguelgrinberg.com/post/running-your-flask-application-over-https
The problem is with your certificate.
The error in your getWebHookInfo:
"last_error_message":"SSL error {337047686, error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed}"
Is Telegram saying that it needs the whole certificate chain (it's also called CA Bundle or full chained certificate).
How to check your certificate:
You can use the SSL Labs SSL Server Test service to check your certificate:
Just pass your URL like the following example, replacing coderade.github.io with your host:
https://www.ssllabs.com/ssltest/analyze.html?d=coderade.github.io&hideResults=on&latest
If you see "Chain issues: Incomplete" you do not serve a full chained certificate.
How to fix:
You need to add all the three needed files (.key, .crt, and .ca-bundle). The Namecheap has very good documentation of how to install an SSL certificate in your site in many different ways, like Apache, Node.js, Nginx and etc. Please, check if you can follow one of the available ways: Namecheap - How to Install SSL certificates
Anyway, you need to download the full chained certificate for your SSL certificate provider and install this on your webserver.
I don't know which service you are using, but for my example, with gunicorn I solved adding the ca-certs with ca-bundle file sent by my SSL Certificate provider (In my case Namecheap Comodo) on my SSL configuration, like the following example:
ca_certs = "cert/my-service.ca-bundle"
For further information: #martini answer on this thread and the FIX: Telegram Webhooks Not Working post.
I have been working with web services connecting to URLs provided by different clients and so far it has all been done using one-way authentication. Now I'm asked to enable 2-way (mutual) authentication for one of the clients. I did a lot of research and reading but still confused about a lot of things.
I could test successfully on my local machine following instructions from various different articles. But the problem is now to deploy it in production.
Here's what I did for testing: I created a test Web service Host and assigned it a self-signed certificate and created a client to test this. After this I created a client certificate using makecert and verified that this is installed via MMC. I then modified my Host app to only allow clients with certificate and tested from client to see the connection refused due to not providing the client certificate. Then I modified the bindings in the client application to include the certificate name and I was able to connect to the Host successfully. So this completes local hosting.
Now the real problem. The tech team is going to create a certificate in "cert store" on the server. And I need to test again to make sure everything works as expected. We have a few different developers who all want to test on their machines on their local code. Can we all use the same certificate somehow? I don't think we would be allowed to import the certificate but what suggestions could I give them so all of us can use the same certificate?
I'm also confused about issues like difference between windows certificate and IIS certificate. What advantages would the IIS certificate provide?
Thanks for help!
Edit: Could one of the differences between installing on IIS be so that the hosted sites be accessed via SSL connection? This would mean we don't really need to install on IIS if it's just a client certificate. Is this correct?
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.