Some users trying to visit my website are getting a warning explaining "This is probably not the site you are looking for".
One of them sent me a screenshot (I'm sure we've all seen this screen before at some stage):
I'm using an SSL cert signed by StartSSL. It's signed for shareshaper.com and www.shareshaper.com.
You can see that the screenshot says that the user attempted to reach www.wamrc.com. I've never heard of that site before. For some reason though, when I visit www.wamrc.com I end up on my staging server.
I've tested my SSL setup with a number of online testing sites and they all report that everything is fine. I can't seem to replicate the issue myself.
What could be causing this error?
Some Other Thoughts
I have another StartSSL certificate I use on my staging server. This one is valid for staging.shareshaper.com and (I assume, can't quite remember) shareshaper.com.
One user who get the warning was using iPad Safari. Another OS X Chrome.
wamrc.com appears to belong to some dude called Oscar Arbelaez.
The issue was initially reported in this Reddit thread
For example it could be an incorrect DNS A-record for www.wamrc.com (pointing to your IP), or an incorrect cname for the same one, but all this is essentially included in the message in the screenshot.
Your server is misconfigured. Its reporting itself as www.wamrc.com.
You need to talk to your hosting provider.
Related
Its a pity google does not offer its domain service in Germany, otherwise launching a react website vial firebase would really be super easy, great service!
The only problem I faced is that the SSL generation seam not to work as described in the documentation.
In Firebase Hosting it keeps on saying: Needs setup
And the documentations says on that topic:
In most cases, your DNS A records haven't propagated from your domain
name provider to Firebase Hosting servers. Troubleshooting tip: If
it's been more than 24 hours, check that you've pointed your records
to Firebase Hosting.
By pointing the records I assume they mean adding two A Type files with provided IP´s.
I added those more than 24 Hours ago and they are as valid as they can be, I checked them multiple times now on my DNS provider checkdomain.de.
Or am I getting something wrong here?
Thanks for any help!
Ok, the problem was that the provider had an additional field outside of the "repository scope" which was titled main IP. This IP also translated into a A entry which could be discovered by the prompt suggested by #FrankvanPuffelen (thanks for that):
dig +noall +answer <your-domain-name>
One the field value has also been changed to one of the IP's provided by firebase the SSL Certificate has been successfully generated.
I hope that it does help someone else in the same situation and I'll try to convince firebase support to add those hints to the documentation.
My website get traffic drop recently. I found that my user cannot access my website when their computer in wrong set of time. However, they can open other website as usual.
The error said "NET::ERR_CERT_DATE_INVALID" in google chrome and "Warning: Potential Security Risk Ahead" in firefox. So, I assumed that the problem is the SSL. Previously I use free ssl from Cloudflare, thinked that its because its free then the error appeared, I the purchased for Dedicated SSL form Cloudflare. But, I keep get the same Error.
Is there is a solution for this situastion?
Changing the user computer time its not my solution here, because other website working just fine.
Thank You
I found that my user cannot access my website when their computer in wrong set of time.
The expiration of the certificate is checked against the local time of the system. If the local time is wrong the check might fail even if the certificate is not really expired yet.
If it fails depends on how wrong the local time is compared to the expiration time in the certificate, i.e. it might be so wrong that some certificates look expired while others are not yet expired. Some sites use more short-lived certificates and thus are more likely to run into this kind of problems. For example Let's Encrypt certificates are only valid for 3 month, while other CA issue certificates for a year or even longer. And of course sites which only use HTTP instead of HTTPS don't have this problem since no certificates are involved in the first place.
Changing the user computer time its not my solution here, because other website working just fine.
There is nothing you can do against this from the server side. And while some other sites work just fine for the moment it is very likely that there are some sites apart from yours which will not work too. So the problem is not restricted to your site only.
I have an application on Heroku. I cname-redirect https://login.zenconomy.se to https://boomeranglogin.herokuapp.com/
I get the following (yellow) error in chrome:
This is probably not the site you are looking for!
You attempted to reach login.zenconomy.se, but instead you actually reached a server identifying itself as *.herokuapp.com. This may be caused by a misconfiguration on the server or by something more serious. An attacker on your network could be trying to get you to visit a fake (and potentially harmful) version of login.zenconomy.se.
You should not proceed, especially if you have never seen this warning before for this site.
Why?
If you want to use SSL and HTTPS on Heroku with a custom hostname (like login.zenconomy.se), you have to purchase the SSL endpoint add-on, get a certificate and configure the setup as described on Dev Center.
I've been trying to research this for hours now, and I can't find any related articles.
I have an installation of MediaWiki that is under SSL and uses an extension of the AuthPlugin to authenticate users to an external database upon their login.
If I access the wiki without being logged in, I can see the content that anonymous users would see just fine. If, however, I log into the site, the wiki is no longer available, and only brings up a 500 Internal Server Error.
I've checked the error logs, and nothing shows up there corresponding to the bad request.
On a staging server, I have the same codebase running under non-SSL, and I do not encounter any issues when logged in, so I'm thinking there might be something to do with tthe combination of SSL and the AuthPlugin.
Anyone out there encounter similar using extensions of AuthPlugin under SSL?
Thanks!
Start by turning on PHP debugging and logging, so you can actually see the error instead of having to guess what the 500 means:
http://www.mediawiki.org/wiki/Manual:Errors_and_symptoms#MediaWiki_Errors
I ran into this same issue for one wiki user after an upgrade. All other wiki users could still log in. My issue was due to the user using a skin that did not work. After changing the user's skin to Vector(default) he could log in again. I couldn't figure out how to change another user's preferences as an Admin, so I ended up running an update statement to the mysql database. Hope this helps someone else.
I have two "Web Sites" running under IIS6 (Windows Server 2003R2 Standard), each bound to a separate IP address (one is the base address of the server).
I used SelfSSL to generate and install an SSL certificate for development purposes on one of these sites and it works great. I then run SelfSSL to generate a certificate for the second site and the second site works, but now the first site is broken over SSL.
I run SSL Diagnostics and it tells me:
WARNING: You have a private key that corresponds to this certificate but CryptAcquireCertificatePrivateKey failed
If I re-run SelfSSL on the first site (to fix it), the first site works but then the second site is broken.
It seems like SelfSSL is doing something in a way that is designed to work with only one Website, but I can't seem to put my finger on exactly what it's doing and figure out how to suppress it. I would manually configure SSL but I don't have a certificate server handy, but maybe there is a way to get SelfSSL to just gen the cert and let me install it?
FWIW I have also followed the guidance of several posts that indicate changes to the permissions of the RSA directory are in order, etc. but to no avail. I don't work with SSL everyday so I may be overlooking something that someone with more experience might notice, or perhaps there is a diagnostic process that I could follow to get to the bottom of the issue?
We had a similar problem today. Our IT guy said he solved it by basically using ssldiag instead of selfssl to generate the certs.
See the reply from jayb123 at this URL: http://social.msdn.microsoft.com/forums/en-US/netfxnetcom/thread/15d22105-f432-4d8f-a57a-40941e0879e7
I have to admit I don't fully understand what happened, but I'm on the programming side rather than the network admin side.