I want to authenticate users with X.509 certificates to my web site.
I can generate an RSA key pair with keygen element of HTML, and then send the SignedPublicKeyAndChallenge structure to the server. The server can then check and sign the public key and generate a X.509 certificate for that key, for the client.
Now, when I signed up at StartSSL, the HTML pages there installed the certificate into my browser’s store without me doing more than clicking a button and I want to do the same. How do I go about that? Send the certificate with a certain Content-Type? Do it with client-side scripting? How do the browser know it’s supposed to install a client certificate?
I know I can tell the user to install it manually, but if it can be automated, then I want to make it so.
You want return the signed certificate file with the application/x-x509-user-cert mime type. The browser should then offer to download or install that client credential.
For further reading, see https://pki-tutorial.readthedocs.org/en/latest/mime.html.
I am working on a very similar application for my own websites.
Related
Our setup is like this: we use a coldfusion 10 server, and files are on a local intranet. Users use a domain login to access any files over https. I'm interested in using html5 websockets, but the first attempt gave me an error because no credentials were supplied. Is there a way around this? If not, is there a recommended technology for this scenario?
The user does log in on the client side. If it's possible, what I'd really like to do here is pass those credentials when making the connection to the server.
you should be able to supply the authentication header to your web socket server before the elevation to web socket read that and send it back in the headers for the elevation (first frame) then when the browser connects it should have the authentication it needs.
if your using a custom authentication E.G in page not authentication header you can also do this by passing any custom header to your server.
Or mandate that the first thing your web client sends is the authentication details this could be something like {username_hash}.{password_hash} if they don't close the socket to them.
Do not do this.
You're now responsible for sending and encrypting the authentication credentials yourself, bypassing something that already works and is tested.
Anyone can snoop on an unencrypted websocket port. Use HTTPs for an intranet, use stable solutions, don't reinvent this wheel because it tickles your fancy.
In a couple of years some colleague will have to maintain this and will have to figure out how your homebrew version works versus something that's solid like plain browser authentication.
My advice: Leave this to the browser and to well-tested coldfusion libraries.
I have a doubt with one request/response across Web Browser and Server with SSL Certificate. Please, imagine the following case (similar question here):
I want that the server, response a HTML to the user (in his/her browser) with access to one file in the FTP, for example:
Download file
In this case, accessing with Anonymous user not generate any problem to access to this file, but if the user has a access with username and password, put this on HTML, it will not be very secure, example:
Download file
I want to prevent that this response with this username and password tag between the server and the user would be catched by "Someone" and get the Username and Password of the user.
The SSL certificate can solved this? Or the best way to do this is create a directory with username and password only with read properties?
Yes, SSL will make it more secure because your communication with the server will be encrypted. It is even better if you have a web server (an API endpoint for instance) receiving the requests from your frontend, contacting the FTP server, getting the file, and responding back with it. This way, the frontend does not need to know about the FTP server. Another good idea is to hash the password before sending it.
Serving the page containing the passwords with SSL (i.e. HTTPS) helps to protect the passwords inside the page. But, the links you provide are for FTP sites and the passwords will be sent unprotected if the user follows the FTP link since ftp:// itself does not use SSL. While there is FTP with SSL (FTPS) it is not commonly implemented in the browsers so you cannot use it. The best would be to serve the files with HTTPS too instead of FTP.
I have an app on a custom domain on Google App Engine and I need to capture JSON packages.
I am using http://www.hurl.it/ to test and the url is like: https://subdomain.website.net.au/folder/
This give a server error however if I remove the S and just use HTTP the request works fine. What does Google need in order for this to work?
Update:
Using Curl and running the following command:
curl --verbose --data "#json.txt" --header "Content-Type:application/json" "https://subdomain.website.net.au/folder/"
I get the error: "unable to get local issuer certificate"
When I download the cert file from http://curl.haxx.se/ca/cacert.pem and run:
curl --verbose --cacert "cacert.pem" --data "#json.txt" --header "Content-Type:application/json" "https://subdomain.website.net.au/folder/"
It works fine and as expected. Does this mean the issue is with hurl.it? if so what is the issue exactly, I have a customer trying to send me data and it is not working either.
Update2:
The issue ended up being that the client did not support SNI so I had to use a VIP instead. This costs money, is an older method but more compatible.
There is an article on how to setup SSL for custom domains on developers.google.com.
Basically you need two things:
An SNI or Virtual IP Certificate
Your domain has to be a payed Google Apps domain to install the certificate
Your certificate, your Google Apps Domain and using the certificate with App Engine will cost you. If you can use the YOURAPPID.appspot.com domain instead you get SSL for free. If you need your custom domain i recommend the above website.
After Updating your Question:
It looks like the Certificate Authority (CA) is unknown or untrusted to the client. This can be fixed by using a commercial certificate from thawte or verisign. Or, you can add the CA certificate to the certificate store of your operating system or client application.
In other words: Install the CA cert as trusted root certificate in your operation system or app. That should do.
Oh and your assumption is right. hurl.it does not know the CA and thus rejects your certificate as invalid or unknown issuer.
Update 2:
Craig, your GeoTrust cert should be fine. Please try the following:
Please verify if you can visit this or any other page hosted by your app with a normal web browser. It should not complain about the certificate. If it does and you need to add an exception rule for the certificate then something is still wrong configuration wise.
I haven't done this in a while but last time i used an SSL certificate i concatenated the actual certificate and the CA somehow, i'm sure there are tutorials for this. Because the CA.cert isn't found it makes sense to provide it in this manner.
From developers.google.com:
'A certificate file can contain at most five certificates; this number includes chained and intermediate certificates.'
See also wikipedia
Since it does work with curl when you supply the CA manually that is a temporary solution for your customer to upload data.
Note that not all applications use the system store for certificates. Firefox for example has its own certificate store and it completely ignores all changes you do in the root certificate store of the operating system (at least under windows that is the case)
Once you have verified that the website works with HTTPS (see 1) you can create a simple form in that app containing a textarea in which you can paste your JSON data and send it to your app using jquery or something. While this is not ideal it is an excellent test to verify that your app and SSL setup works and the issue is somewhere else.
If upload is all you need at the moment you could always package curl and the CA.cert together and add a small batch file that makes the appropriate call.
This is all the information i can give you without having a look at your actual setup. My advice is to fiddle around with clients and certificates because that's definetly where this issue is. It has nothing to do with the JSON data.
I have created an application from Box developer account, but I couldn't able to set the redirect url as http. I have seen that Box API supports only https. As I hosted my web application as a module of another web application, I cannot change it's protocol to https. So is there any way to set the redirect url to http?
Please find me a solution for this.
Thanks in Advance.
Since the redirect URL is used to send you your application OAuth2 tokens, You are essentially asking Box to send you confidential information in the clear. It's just not a good idea, since anyone that installs a network sniffer anywhere between you and Box can just sniff those tokens and start using them.
If you don't have the ability to ask your server hardware or hosting web application for an encrypted connection, it's probably time to upgrade your service provider or web app.
Is there an extension API which allows to access client certificates? I would like to provide a modified certificate selector based on details of the certificate.
Additionally, as far as I understood, Google Chrome does not provide its own client manager but uses native solutions for client certificate management. Due to this, full certificate management may not be possible by design. But since Chrome allows to generate and import certificates generated by the html5 tag I was wondering if an extension could import client certificates.