Client certificate selection - apache

I have a https apache server that needs client verification. But when somebody is browsing this site there is need to select proper cert from list of certificates installed in browsers. What can I do to become client cert default to my webpage (so clients do no need to select cert)

Is your certificate valid and signed by a 3rd party root authority like Thawte, Verisign... etc?

You can't control from the server which client certificate is presented - you can only indicate that you expect a clientside certificate (SSLVerifyClient). Most browsers allow the user to associate websites with individual client certs. There is no way to manipulate this from the serverside.

Related

StartSSL just for encrypted data transfer

I am developing browser extension, that sends some data from currently browsed page to my backend server. User is aware of it, it is intended.
I don't want to cause any user-data exposure, when the user is e.g. on unsecured wifi. So I just want to ensure, the data and the url goes over the net encrypted and only my backend will see them.
Do I understand correctly, that any SSL certificate, even free one from StartSSL will do the trick?
What other side effects with free SSL certificate should I consider?
- will the user's http-client trust such a certificate?
Thanks.
The SSL certificate will do the trick as long as it can be validated. That means that the root certificate of the certificate chain needs to be within the trusted certificate store of the browser.
Furthermore, the certificate will have to be for the right address (URL), must not be revoked, CRL's and OCSP must be configured correctly etc. etc. In other words, the usual steps required to have your web-service certificate validated must be met.

SSL Certificates for just API or do clients need them to?

I have a RESTFul API that I want to secure using SSL Certs. If I were to get some SSL certificates, would I need separate ones for each of my web clients that use my API or would the API be the only thing that needs the certificate?
The SSL certificate is installed on your web server hosting your REST API. The clients don't need to have a certificate to securely exchange data with your server.
Think about all the e-banking/e-shopping sites that you probably use. You don't specifically install any certificates on your computer to be able to use them. As long as you trust the certification authority that issued the certificates to those websites (handled by your computer transparently), your computer can connect to them over SSL.
So, as long as your own server's SSL certificate is valid and issued by a trusted certification authority, your clients will be able to connect securely over SSL without needing separate certificates.
SSL Certificates are for Web Server. You install them in your Web Server. Certificates are matched to your domain. They have nothing to do with the clients. Any client can access your server if you have a valid certificate.
I think you have multiple Resful API's.
Now you need not have separate Certificates for API's since Certificates are matched to your server's domain and not to the API's you host. You can have any number of API's and Clients connected to your server using a SSL Certifcate.

Create my own intermediate cetification authority from commonly trusted certificate

I have a simple question (maybe stupid) and i didn't find any clear answer to it. If i get a certificate from a trusted signing company (like verisign...) for one of my server (web for instance), i'll have private an public keys. With this certificate can i set up my own intermediate CA and sign cert request and the be trusted by every one (i know that's shouldn't be..)? My real question is : what will prevent me for issuing certificate and how the company can garanty that nobody does ??
Thanking in advance!
The certificate issued for your web site is suitable for SSL/TLS and is not suitable for issuing other certificates (Key Usage field is different). Consequently while you technically can generate another certificate using yours as a CA, such generated certificate won't be trusted by properly implemented and configured validators (those that check Key Usage).
You are not paying verisign or other certificate organisation for the certificate publishing but for the certificate validation, this meens that they have web services that respond if your certificate is valid or not, if it is still active and not expired and your contact information as requested.
Unfortunatly this is something you have to live with it and pay them if you really need ssl over your site.
I have used a homemade certificate for my lan server and when i visit this https site a big red warning notifies me that this site is malicious and it has not a valid certificate. This doesn't bother me but I am sure that all of my clients would have freeked out if they see such a bold warning popping up to their browser.
what can you do? it's a companies' world

Am I required to setup a usermapping for a clientcertificate in order to have client certificate authentication to work as expected (in IIS)?

Linked to my question about client certificate authentication done the right way I was wondering whether I have to take the step to link a certificate to a user (active directory or local user) in order to have clientcertificate authentication to work as expected?
And is it necessary to disable all other authentication schemes (anonymous, windows) for clientcerticate authentication to happen?
See this question on the IIS forum:
This is what I would like to achieve:
A SSL-certificate for the URL itself (https://example.company.com). To my understanding this certificate does not have any connection whatsoever to client certificates.
Client certificates issued from my local CA and shared to trusted clients.
Some way of specifying which client certificates are allowed to connect to a specific IIS web site.
3 seems... complicated, to say the least. If I just set everything up and connect with a client certificate I have issued it works. The CA and the web server are on the same domain (if that matters), and I have added the root certificate from the CA to the trusted CAs on the web server. However, at this stage I have not told the web server which client certificates to accept, so my first guess was that it accepts all client certificates [chained to] any CA it trusts.
See also this question, which links to this site, which is dead.
It comes down to creating a "Certificate Trust List", or to mapping certificates to user accounts.
You can however implement a custom certificate validator in your service, how to do so is explained here.

Is it possible to use https (own-server) without paying anything?

I want to use SSL (https) to secure communication. Is it possible to do it without buying a certificate of some sort?
You can use a self-signed certificate (google it) but your users will get a message saying the certificate is not valid. The traffic will still be encrypted, however.
The reason you have to pay a third party for a "valid" SSL certificate is that part of the purpose of an SSL certificate is to verify the authenticity of your server. If any body could issue an SSL cert with any information they wanted, what's to prevent me from setting up an SSL certificate using Walmart.com's contact information and tricking users into thinking my site is a branch of walmart.com?
In short, you can get the encryption part for free, but if you want to avoid browser identity warnings, you'll need to pay for a third party cert.
You can self sign a cert, or get one from cacert.org or a related free signing community. Most browsers will throw up warnings, so you shouldn't do it for production (if you are an ebusiness), but during development, or if you don't care about the warnings, it's a cheap alternative
As others have said, you can simply and easily use self-signed certificates or set up your own certificate authority (CA) and then issue as many certificates as you want. All these certificates are as valid as the "commercial" ones issued by the big CAs, so there is no technical difference between your certificate and the one from, say, verisign.
The reason most browsers and other client applications warn about your certificate is, that they do not know and therefore not trust your CA. Browsers usually come with hundreds of well-known CA certificates everyone automatically trusts (if thats a good thing, well...), so you don't get a warning when visiting amazon.com via HTTPS. In Firefox, you can go to "Preferences" > "Advanced" > "Encryption" > "View Certificates" to see which CAs or individual certificates your browser currently trusts.
In the end, it's a question of whom you and the users of your service trust. If your users know and trust you (say in company network or a small development team), they can add your CAs certificate to the trusted certificates in their browser. From then, every certificate issued by your own CA will generate no warning and will be trusted just like every other certificate.