I am new to development and at my new job we have this issue where on a sub-domain users are getting the error you see below but when they go to the base domain (e.g: domain.com) they don't see that.
I am supposed to solve this but not sure what might be causing it. I am not looking for somebody to solve this for me but if you can outline possible reasons why, i would be very thankful.
First thing: open up the "Technical details". They will give you more information, information you might or might not yet fully understand, but it still have the necessary info.
Basically, SSL (https) certificates are created for a specific domain. If the domain name changes (from e.g. example.com to foo.example.com), the certificate can not be used without a security warning popping out.
You need to create (either by self-signing or purchasing) separate SSL certificates for all the host names/domains under which the site will be accepted, to avoid the security warning. An alternate option is to purchase a wildcard certificate for the entire domain and sub tree (ie: *.example.com).
There are, to the best of my knowledge, no other ways around this; it's one part of how the HTTPS security is established.
When you're running HTTPS, you should have a different certificate for each server (subdomain) not each domain and the client should trust it if you don't want them to see this error.
You can use a wildcard certificate also. It would inherit through all subdomains.
Related
I've seen this question around here on the forums only what I wish to know slightly differs from the ones I already read I suppose.
I will give you an example of the problem I am facing:
Let's say a hacker has managed to infiltrate the system and is able to spoof a DNS. Now if this hacker would clone a website, let's say this website is facebook, what I have read so far he would be making a HTTP website, because HTTPS would show up as faulty.
Now what I'm wondering is that with modern SSL it would seem like everyone is able to get his own certificate for his website. So if someone would connect to that website it would say the connection is trusted because it's SSL with a legit connection.
So what if this hacker would add a certificate to his cloned/spoofed phishing website? Wouldn't this mean that me as a user would go to his facebook page, and in the search bar it would say the connection is legitimate ( Because he added a certificate ) ? Because if that would be the point it would be necessary to check the certificate of every website I open at all times to see if it's actually the certificate that belongs to facebook (For example.)
Please let me know if anyone has any knowledge about this I am very curious to see how this works!
Provided that
Let's say a hacker has managed to infiltrate the system and is able to
spoof a DNS.
means that the attacker has control over the records for the name facebook.com (in orther words, he can point www.facebook.com to an IP of his choice) then yes, your scenario is correct.
He would
redirect www.facebook.com to site of his
buy a certificate for www.facebook.com
Someone going to that site would then see (www.facebook.com would be the domain)
This means that the traffic to access to this site is correctly secured between the browser and that site, and nothing else. Specifically, this does not tell if the site actually belongs to Facebook.
There are some sites which go one step further, with Extended Validation Certificates, where the issuer does some checks to "ensure" that the certificate is delivered to the actual owner of the service. You the see something like
As you can see, the owner of the site is visible right on the toolbar. Other browsers usually use a bright green toolbar to signal such sites.
Not sure if that is what you're asking, but you have trusted CAs imported to your browser (by default).
The attacker would need to have a key signed by trusted authority for this particular domain. I do not expect that to happen.
Another option would be breaking the key - very unlikely with current technology/regular updates made by major browser providers.
Major browsers providers are deprecating vunerable alghorighms to make sure you're OK.
For instance - Recently for that reason SHA1 got depreceated.
See here for more details on SHA1:
https://blogs.windows.com/msedgedev/2016/11/18/countdown-to-sha-1-deprecation/#pjXdGbOji3itBI7v.97
https://security.googleblog.com/2016/11/sha-1-certificates-in-chrome.html
https://www.google.com.au/search?q=firefox+sha1+deprecation&rlz=1C5CHFA_enAU714AU715&oq=firefox+sha1&aqs=chrome.1.69i57j0l5.2293j0j4&sourceid=chrome&ie=UTF-8
)
To summarize - your browser will let you know that there is 'something wrong' with the site (warning instead of green box).
Simply check the green box (and domain). Keep your browser updated.
Also for more information about SSL handshake see here: https://www.ssl.com/article/ssl-tls-handshake-overview/
So I made a contact form in Laravel 5, that's completely working. It basically posts the email, name and message to a variable and sends me an email with them. Is this secure enough for real life use without an SSL cert?
My project files are outside of the public_html folder if that makes a difference. I want to have this usable (security-wise), but don't want to pay a ton of money for an SSL cert on a site hardly anyone will go on.
Any answers appreciated
SSL is always recommended, but if the contact form shouldn't get any sensitive data, then you can live without it.
Though now you can get SSL certs for free from LetsEncrypt.
I recently bought SSL for my website and want to create a section within the site in the form of https://secure.example.com/member/upgrade.aspx. However, I am having a hard time solving this issue since currently my website URL rewrite prohibits any subdomain and the user is logged out if he or she gets transferred to the above link.
I have search online and found some good information such as dynamically create the url without actually creating a subdomain in IIS.
Questions:
What steps are needed to achieve the objective above?
Should I have bought the wildcard certificate instead of one for a specific subdomain?
Thank you.
One option would be ignoring that url pattern for rewrite purposes or ignoring the url if the protocol is HTTPS. That said, I would take a slightly different approach here and just put the entire site behind SSL -- rewriting all the queries to the other protocol works and google is now giving rankings bumps to HTTPS so there are good business reasons to make the switch. You are already taking the pain of getting SSL involved at all -- the dedicated IP and certficate cost the same if you use them on a single page or all the pages, might as well take advantage of it and ease your management burden in the same motion.
Is it possible for crook to redirect website site/landing to your domain to elsewhere? Say, a visitor's intended website is, knowledgenotebook.com, but the crook redirected the user to google.com or yahoo.com or anything else? And doing so randomly, so, it can try to avoid detection.
I believe you can do that with DNS cache poisoning or XSS.
With DNS poisoning it would still say knowledgenotebook.com in the URL. With XSS i think it would have to have the new URL.
What do you mean by randomly? As in user X will get redirected but users Y and Z will not? If that is what you mean then they could probably randomize it with XSS. I don't think it could be randomized using DNS poisoning...
Yes it is possible. He can use several techniques to achieve that like DNS hijacking, IP spoofing, ARP poisoning, edition of hostfile etc. Hakin9 is a very good magazine for beginners (but not only) interested in security matter
Yes, he can do it by modifying the hostsfile
Yes, it is possible. The best way for your users to ensure that they are actually getting your site is to use an SSL certificate. The HTTPS protocol requires browsers to verify that the domain name it is trying to get matches the domain name of the certificate (otherwise you'll get a security warning in your browser).
There's not really any way to prevent all the possible ways that someone can do this, as it can happen anywhere between your server and the user. DNSSEC is supposed to help with some of these issues, like cache poisoning.
We extensively use a third party app that we'll call thirdparty.com. thirdparty.com and mysite.com have a common navigation and look and feel, so to the users, they think they are always on mysite.com.
What we're going to do is start url rewriting 3rd.mysite.com to display thirdparty.com, to make it look even more like a seamless experience. This also gives us access to thirdparty.com's cookie, because it will be written as mysite.com.
thirdparty.com has an SSL cert that they use for a few select transactions (basically just login). When you call https://3rd.mysite.com/login, you get a 404 as mysite.com does not have SSL. So we're going to install an SSL cert to the 3rd.mysite.com subdomain to alleviate this problem.
The question is, if we install a EV SSL certificate, will the user see that, or will it relegate to the cert from thirdparty.com? I can think of reasons for this to work both ways, but am looking for a definitive answer. If they see the SSL cert, then there's no sense wasting money on the EVSSL. If they see the EVSSL, I'd think that would be a big opening for phishing if someone was doing this illegitimately.
Cheers
If user agents see the site as thirdparty.com they are going to require an https certificate for thirdparty.com. So if that's an EV cert, then they are indeed going to see the green glow. Of course, you will want to make sure any communications between thirdparty.com and mysite.com should be appropriately secure.
(BTW: rfc2606 for example domain names.)
Disclaimer: I'm not really competent to answer this question, but this is stackoverflow.