I have a CMS that I've developed similar to wordpress that is geared for small businesses. Typically one user uses the system to make changes. Recently Firefox 51 is displaying a notice that says "This connection is not secure. Logins entered here could be compromised. Learn More"
I have deployed this CMS on numerous websites. Now, from what I see, Firefox wants me to install an SSL on each one of these? This really isn't practical or is it? Is there really a threat? Now I feel like my users will be scared and deter them from using the system.
Is this an issue for wordpress users? Is there a relatively simple solution?
This is the reply I got from Host Gator regarding support for Let's Encrypt
While our System Administrators are certainly looking at the
opportunity to incorporate open SSL certificates in the shared
environment I do not currently have a time line to implementation. As
of now if you requested us to install a Let's Encrypt SSL Certificate
it would be treated as a 3rd Party Installation and incur a $10 fee.
Additionally, though I understand this may not be an ideal solution,
you would be able to perform these installations and attempt to
configure the automatic renewals on a hosting package with root level
access, such as a VPS or dedicated server.
I want to also note that I have a dreamhost account and it took only the click of a button to add and SSL to a domain. So easy, really hope to see other host's follow suit.
SSL is now fairly easy to obtain or add to your sites, most of the hosting provider supports AUTOSSL in WHM panel which is free and you can add ssl to each of your domains by just clicking or you can also install Let’s Encrypt. You'll just need a hosting provider to support it.
While you can ssh to your host and install letsencrypt and automatically renew those certs every 3 months.
But in your case if you are using hostgator, you can obtain StartSSL Free cert, you can generate your Class 1 certificate for free for a year then follow their guide on how to install third-party ssl certs hostgator? .
Firefox and Chrome have added those notifications to HTTP screens that have login forms.
You really should add SSL certificates to your sites. Let's Encrypt makes the whole process pretty dang easy. If you don't want to, or don't have the technical know-how, using a free CloudFlare account with flexible SSL enabled will do the job as well.
You can disable that message going on about:config, search insec, than double-click the line security.insecure_field_warning.contextual.enabled
This will set that option to false and you won't display that message anymore.
Related
So my wordpress site domain is from Godaddy, and hosted in a hong kong server, as our target users are mainly from hong kong. When i wish to improve SEO and started submitting backlink to directory sites, i always get the error message of "The URL could not be validated. Either the page does not exist or the server cound not be contacted."
I have read from another platform that someone commented: You're getting the error because you're using an SSL that belongs to someone else. When these directories attempt to verify your site using the "https", they get a warning that says your site is potentially harmful and the third party SSL is the reason given. My suggestion would be to buy an SSL directly from your web host or from a reputable SSL company."
But unfortunately, i can't ensure if this is the right direction and how can i do that.
Could someone teach me please? By the way my website link is , hopefully you can find some clues with the link. Thanks in advance.
https://www.bananaportal.com/
Have you tries https://easyengine.io/docs/lets-encrypt/
Most trusted and almost free SSL certificate for everyone to install fully Secure and trustable certificate that widely accepted in the world.
The certificate itself is fine. You can see the results of two different tests here:
https://www.sslshopper.com/ssl-checker.html#hostname=https://www.bananaportal.com/
https://www.ssllabs.com/ssltest/analyze.html?d=www.bananaportal.com
Many directory sites are unable to process https, and that might be the source of your problem. In any case, directory sites aren't going to improve your SEO anymore.
The issue relates to esoteric web browsers, you can read more on it here: https://community.letsencrypt.org/t/some-browser-say-certificate-is-not-trusted/28766
It is also important to mention, that your current certificate is doing perfect on encryption, but the authentication is the simplest and cheapest (free) possible. You've never showed any legal document that prove your claimed identity, in order to receive the certificate.
You can be more impressive with a Verisign payed certificate.
I’m building a web application where users can create their own websites. Users have the option to point their own domain names at these sites. A prototype for the application already exists; Apache accepts requests on all hostnames and the actual domain mapping and resolution happen at the application level (a simple database lookup grabs the site that matches the requested hostname).
Where I’m stuck is how users’ SSL certificates might fit into this equation. What steps would I need to take to allow a user to upload their SSL certificate such that the application could successfully handle secure HTTP requests to their hostname? Is this even something the application alone could handle?
I think you cannot handle this in your application alone.
It's a CA problem, except you are an intermediate CA company, or you cannot get the user's domain SSL certificate and sign for user's domain.
The typical user, and IMHO even more the user's who are going to create a web site of this system as opposed to setting up their own WordPress or other site on their own server (or their own paid shared server hosting account), will have absolutely no idea how to setup a proper SSL certificate, so getting it to your securely so that you can install it wouldn't even be an issue because they will never get that far.
However, you should be able to use Let's Encrypt to do exactly what you need. As part of the process of adding a domain, once the domain is pointing to your server (the users will have to figure out how to do that with their domain registrar), you can create a Let's Encrypt certificate and validate it. My favorite web hosting company (I won't name it as that is not relevant - anyone can do this with some effort) provides this capability as part of their Control Panel. They also provide paid certificates with a few of the big issuers, as they have for many years, but for most small sites Let's Encrypt works very well and is totally free. The setup literally takes only a minute. The key is that you have to give the user an IP address or CNAME first so that they can point the domain. Once the domain is resolving to your server, you can get the Let's Encrypt certificate.
I am a developer working on an ASP.Net Web Application that uses forms authentication.
In my experience I have always worked in an environment where we use SSL to protect the web pages according to permissions.
In my new company my manager has asked me whether we need SSL and can we do without it.
We are using a private network for the application and do not anticipate any heavy duty hackers.
However it is useful that permissions protect webpages from unauthorised users.
So what is the best way of tackling this?
That depends on your security needs :-).
If you trust everyone who has access to the network (this includes people like cleaning staff and external contractors) not to install sniffing software and do bad things with the passwords and personal data they sniffed, then you can do without TLS. Otherwise you need it. That's up to your manager to decide.
If it's a private network (i.e. Intranet and everyone is 'trusted') then like #sleske mentions you don't have to use SSL for anything.
That being said my question is what is the manager's reasoning for not using SSL where it makes sense? If it's cost then you could have your own (company) CA rather than using a commercial CA. Most places I've worked have setup a CA on one of their server's (which may or may not be trusted by VeriSign or one of the other commonly used CA's) and that was used to issue certificates to internal web servers. All computers on the Domain were setup to trust the company's internal CA.
As far as SSL/permission protection of your pages/content:
SSL protection is a separate topic from 'permission' protecting your pages. SSL is just encrypting the http traffic from the client (browser) and the server. Protecting your pages is up to you using permissions and checking that the user is authenticated, the mechanisms for this don't change based upon (not) using SSL.
I’m developing an Intranet application and I want to make a secure authentication.
One approach can be use “https”. The problem is that the server doesn’t have a trusted certificate, therefore is a bit annoying for the client because the browser doesn’t trust in the certificate and complaints with a scary message.
Using http will compromise the user password but it can be combined with “Digest access authentication”
What do you think?
As of November 2015 you can't buy certificates for internal domains so as far as I know the only option is to pre-install the certificates on clients. Not a great solution.
Another possability if you want to keep your internal domains private is to create a public domain: mycompany.com, and then run your own DNS server internally that resolves your internal domains: accounting.internal.mycompany.com, hr.internal.mycompany.com and so on. Then I believe you can use a wildcard certificate for mycompany.com. I haven't tested this solution.
These are (y)our options:
If you have mostly Windows hosts, you can Distribute Certificates
to Client Computers by Using Group Policy | Microsoft
Docs
and use your own self-signed certificate in this way.
Non windows users or Windows machines not in the domain will have to
go through the hoops and warnings of either installing the
certificate properly manuallly or allowing the self-signed certificate.
A bad user experience.
You use a proper domain name, a real certificate and a messy DNS
configuration where www.mycompany.com resolves to an external site,
but wiki.mycompany.com is an internal site (But please, please don't put the internal
address for wiki.mycompany.com in an externally visible DNS record!)
You don't use HTTPS at all and use HTTP. Possibly by inventing your
own security for login pages (Yikes!)
They all suck.
Especially if you want to distribute an enterprise-ready onsite app, and you don't know the customer's network and DNS configuration beforehand.
Purchase a domain and trusted certificate? They are really not that expensive anymore if you shop around.
Having said that, digest access authentication is reasonably safe for authentication. Using http rather than https, all of the information you send across the wire will be plain text even if the password is not. Anyone that can plug a laptop in to your intranet running an application such as WireShark can view all of the information sent back and forth. If you care about that information not being compromised, http will not meet your needs.
You have these options:
Purchase a trusted certificate.
Or, generate your own root certificate, install it in browsers on all intranet computers (you should be able to do it since it's intranet), generate your own server certificate signed with your own root certificate. This is actually what companies often do.
Note: Digest access authentication is not helpful if you want to have form authentication (a HTML form with user, password, login page using the visual style of your app, nicer wrong-password error reporting, possibly additional features such as "remember me" or "forgot password").
If you need it to be a fully secure, you should purchase the SSL certificate.
From the wiki link you provided:
Disadvantages
Digest access authentication is intended as a security trade-off; it is intended to replace unencrypted HTTP Basic access authentication which is extremely weak. However it is not intended to replace strong authentication protocols, such as Public key or Kerberos authentication.
I think there's your answer :)
Im trying to share a wildcard SSL cert across many applications. The way it would work is users would have websites with thier domain, but when they need a secure connection they would be redirected to a designated SSL site like https://client422.domain.com
Can session data be shared across the domains even if I place both domains on a single site and a single App Pool?
I wrote a blog article on creating a wildcard cert with OpenSSL (although the article could have a typo or two in the openssl config part, if you figure out the config, it will work as far as the openssl commands are concerned).
http://codingathome.blogspot.com/2008/11/creating-self-signed-certificate.html
If my article is too difficult, and if you have linux available, i've heard that tinyCA is the way to go.
Now, as far as 'session data' sharing goes, thats a whole different ball of wax. I'd say its possible if you store session data on server side.