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.
Related
I was recently looking around at some of the features my current web host offers, and am now wondering about a few things. Even if you can only answer part of this, I appreciate any help you can provide.
I have a domain, mydomian.com, and the host offers shared SSL so I can use HTTPS by using this address https://mydomain.myhost.com. The SSL certificate is good for *.myhost.com.
I don't know a lot about SSL, but I'm assuming this means that the data between site users and ANY domain on myhost.com is encrypted. So was curious if this meant that if someone else on the same host as me somehow intercepted the data from my site would they be able to view it, since they would also have a https://theirdomain.myhost.com address, which uses the same SSL certificate? I may have no idea at all, and this was pretty much a guess.
If HTTPS is used on a login page, but after logging in the other pages are viewed over HTTP, is this a security issue?
Is there any way to show a web form via HTTP for bots like Google, but have real users redirected to the HTTPS version? Would be ideal if this could be done via .htaccess. I currently have some rewrite rules that redirect certain pages to HTTPS, but the rest as HTTP. So if a visitor visits the contact form they get the HTTPS version automatically, but it automatically switches back to HTTP for pages that don't contain forms. So, via htaccess, is there a way to direct real users to the HTTPS version, but have bots directed to the HTTP version? I would like these pages to still be indexed by the search engines, but would like users to see it via HTTPS.
Thanks in advance for any help you can provide.
I'm going to guess you'll be okay for number one. If your host does it correctly, individual subdomains never get to see the SSL keys. Here's how it would work:
Some guy with a browser sends an encrypted request to your subdomain server.
Your host's master server receives the request and decrypts it.
The master server sends the decrypted request to your subdomain server.
And any HTTPS responses you send back go through that process in reverse. It should be easy to check if they've set things up that way: If you can set up shared SSL without personally handling any key files, you're good. If you actually get your hands on some key files... not good.
For two: If you encrypt the login, you protect the passwords, which is good. But if you switch back to HTTP afterwards, you open yourself up to other attacks. See: Firesheep. There may be others.
And for three. Yes - definitely doable. Check out mod_rewrite. Can't give you an example, as I've never used this particular case, but I can point you to this page - particularly the section entitled "Browser Dependent Content."
Hope that helps!
Every traffic is encrypted, when you use https:// as protocol. (Except for some uncommon circumstances I won't talk about here). An SSL certificate's purpose is to prove the identity of the server, by combining it's public key with an identity. This certificate is only usable with the private key that belongs to the public one. In your case it seems that this certificate as well as the key-pair is provided by your hosting provider. I guess that neither you nor the other customers on the host have access to this private key. That means that only your provider is able to decrypt the traffic. Since that's always the case (he's running the server, so has access to every data), that should be no problem.
In most cases it is a security issue. On every further unencrypted http-request the client has to provide some information of the session to the server. These can be intercepted and used by an attacker. (simply speaking)
The bots should support https, why not redirect them? Anyhow: The important part is not to provide the page containing the form via https. To protect your user's data you should take care that the response is transferred via https.
A number of Countries have implemented electronic id cards, that their citizens can use to securely access online facilities like banking.
I am interested in learning how to support these cards, but tracking down documentation on how to do this from an IIS hosted website is a real PITA: In MSDN for example the bulk of the smartcard documentation covers the end to end scenario of linking smart cards to domain logins in a corporate environment.
I am just trying to authenticate the holder of - for example, a Spanish DNI-e card and perform an OSCP validation of the card via http://ocsp.dnie.es/
Now, its seems that, rather than explicitly detecting the smart card insertion, I need to create a login page on the server with SSL client authentication forced - but how do I configure one request to require ssl client authentication and to pick the correct client certificate?
Indeed, configure your server to require client certificate authentication. You will receive the client authenticator details in the headers.
You can force to only accept specific certificates by configuring the public root certificate of those client certificates on the server and removing all others that you are not interested in. In the authentication request going from your server to the browser, only the root certificates are listed that are trusted on your server system. The client browser will only offer client certificates that are somehow related to that root.
In an Microsoft environment you would configure your IIS to require SSL on your login page. Additionally, require SSL client authentication using a 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.