All my local sites are .test but for some reason when I access some of them i get NET::ERR_CERT_COMMON_NAME_INVALID.
What's weird is that the error message points to another local environment.
This server couldn't prove that it's *****c.test; its security
certificate is from ******ing.test. This may be caused by a
misconfiguration or an attacker intercepting your connection.
I'm not sure how to resolve this. I tried deleting the certificate but nothing happened.
********ing.test Issued by: Laravel Valet CA Self Signed CN Expires: Saturday, January 21, 2023 at 17:09:55 Eastern Standard Time
"****ing.test" certificate name does not match input
I'm hiding the URL's for privacy purposes.
Fixed it by updating my updating my valet from 2.18.9 to 3.2 and running valet secure.
Related
Has anyone had issues with Lets Encrypt SSL certificates with Avast Internet Security?
We are getting some reports that Avast Internet Security is blocking the connection.
This is a screen shot from a clients computer (yes old windows, but still an issue regardless).
We have also had reports on a totally different server, hosted by a totally different company as well. Same error, but this time on a mobile device using chrome.
Has anyone come across this yet?
This might be related to one of the Lets Encrypt certificates expiring on September 30th, 2021.
Here's another question that talks about this: LetsEncrypt Certificate invalid/expired when seemingly not in PHPMailer, TLS, Openssl, file_get_contents, Sep 30 2021
I tried to show js problem at my https://streamgeeks-rebranded-dev.cloudns.cl/ site
But I got a feedback from one of users :
My connection block that site ^^
The security system of the network operator blocks me saying that it is "a possible malware" –
service
sslshopper.com/ssl-checker.html#hostname=https://streamgeeks-rebranded-dev.cloudns.cl
shows :
streamgeeks-rebranded-dev.cloudns.cl resolves to 18.198.221.45 Server Type: Apache/2.4.41 (Ubuntu) The certificate should be trusted by all major web browsers (all the correct intermediate certificates are installed). The certificate was issued by Let's Encrypt. The certificate will expire in 6 days. The hostname (streamgeeks-rebranded-dev.cloudns.cl) is correctly listed in the certificate.
I run manually :
sudo certbot renew --dry-run
after that I read :
The certificate will expire in 66 days
Could you please to run my site and say if you have any problems opening it ?
Thanks!
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.
We had an issue with our automated build machine yesterday. We are using a TFS Build server, and when it tried to automatically download NuGet packages, we got the infamous "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel" error.
There are a lot of threads around the 'net regarding why this happens. That isn't my question. It can be fixed easily enough by changing your NuGet repository from
https://nuget.org/api/v2/
to
http://nuget.org/api/v2/
or
http://packages.nuget.org/v1/FeedService.svc/
What I'd like to know is why the repository is using SSL in the first place? I assume it is there for a reason, but I can't figure out what. There is no login that would require security. I can't think of any information being sent that would need to be secure. I just want to make sure that by using an unsecured connection (which works just fine) we aren't somehow compromising our build machine.
Can anyone explain what is gained from connecting to NuGet using a secured connection?
I can't think of any information being sent that would need to be
secure.
It is not necessarily because the information you exchange with nuget.org contains anything secret and thus needs to be secure. By using using SSL you will be certain that it actually is nuget.org you're talking with. Without SSL, somebody might in theory be feeding you bogus packages, and that might be a security problem.
As for the issue you're experiencing with "Could not establish trust relationship for the SSL/TLS secure channel", we've had a similar problem when we started using a new build server:
If you look at the SSL certificate presented by https://nuget.org/, the certification path is: GeoTrust Global CA > RapidSSL CA > *.nuget.org
GeoTrust Global CA was missing as a trusted CA on our new build server, so the problem was easily solved by adding them to the build servers list of trusted root CAs (using the MMC console with the Certificates snap-in).
Update:
On a later service, I've experienced the same SSL issue, and adding GeoTrust as a trusted CA alone didn't solve the problem. In addition, the server was also missing to root CA for https://go.microsoft.com/, which is Baltimore CyberTrust Root (go to https://microsoft.com, and you'll be able to view and download the certificate). Adding this to the servers list of trusted root CAs solved the issue.
I've noticed that this question has been asked several times but none of the results provide a solution to my problem.
I am developing a website for a client. The website is http://www.entirelyintimate.com.
It is a dropshipping website that uses Paypal Pro for their checkout process.
We purchased and installed the SSL from Godaddy.
According to an SSL checker website, the chain and installation appears to be correct.
I removed all insecure content on the pages that need to be secured
1 example - https://www.entirelyintimate.com/checkout-complete
I checked the page on - whynopadlock.com and it appears to be good there.
But... I still receive the dreaded Error code: sec_error_revoked_certificate
I am pretty new to SSL so I could be overlooking something basic. Any help would be appreciated.
p.s. This community is really great. I come lurking here all of the time when I have questions. I do an automatic click when I see this website in the Google search results.
sec_error_revoked_certificate means that the certificate has been revoked.
Your certificate may be issued by a CA trusted by your browser and valid in time, but the CA may have revoked it, and your client is checking for revocation (which is recommended).
Certificate revocation is a mechanism that makes it possible to invalidate a certificate before its normal expiry time. Checking for revocation can be done via CRL or OCSP by the clients.
Typically, certificates are revoked upon request from the entity corresponding to that cert (i.e. the user or the server admin) if the private key has been compromised, if the CA decides the validating data wasn't sufficient after all, or perhaps automatically if the CA issues another certificate to the same entity.
A possible cause for the problem could be that you might have re-keyed your certificate, thereby making your CA revoke the old one. If you're still using the old one inadvertently (perhaps it's still available to your server in its keystore or equivalent) this error could happen.
Qualys SSL Labs's SSL checker is generally a more complete tool for checking your SSL/TLS configuration. It seems to indicate that your certificate has indeed been revoked.
The error cause is exactly as stated: the security certificate has been revoked.
You can verify it here by entering the checkout page address.
I am afraid you will need to check this with GoDaddy.
0x4F0DB30A63474B: revoked
This Update: Sep 11 17:52:23 2012 GMT
Next Update: Sep 11 23:52:23 2012 GMT
Reason: cessationOfOperation
Revocation Time: Sep 10 01:39:38 2012 GMT