I have some local virtual servers simulating an Intranet at home. I have server who acts as a Root CA and also as a Intermediate CA. I have a web server configured to use HTTPS with a certificate signed by the intermediate CA.
Question: Is there a way to use HTTPS without installing the Root Certificate or the certificate chain file on every web browser of the Intranet clients?
No, the certificates must be installed into the CA root trust store on each individual system. If you have a domain with Windows clients you can use group policy objects to perform the distribution but other than that I'm afraid you'll need to do it the old fashioned way (which can be cumbersome depending upon the platform; like chromebooks).
Related
I'm building a PHP web app that uses AWS RDS. In order to make the connection encrypted, I need to download the SSL certificate from RDS and store it on the app server so that the app can use it. But I remember when I use SQL workbench it somehow knows how to connect with SSL to the RDS instance without me downloading the certificate and telling it where the certificate is stored. Also after reviewing the way how HTTPS works, I know that the client doesn't need to store a certificate the first time it connects to a server, it download the certificate itself. So my question is for my app to connect to RNS instance using SSL, why do I need to first download the cert and tell my app where it's stored? Shouldn't my app know how to get the certificate itself?
Certificate validation requires a trusted root CA. Trusted means that the CA is in the local trust store. Depending on what site you connect to and what certificate you get it might be a certificate issued by a CA you already trust or not. In the latter case you would need to explicitly get the so far untrusted CA certificate first and somehow treat it as trusted.
The need to explicitly import a CA as trusted is typically true for self-signed certificates which is usually considered bad practice but depending on the specific environment might make sense. It can also happen for company specific CA but these should better by rolled out to the various systems by an automated process. It might also happen when a misconfigured server does not send a required intermediate certificate, in which case it would be better to fix this server.
Note that you should not import arbitrary CA certificates and consider these trusted. Whoever owns this CA can issue arbitrary certificates even for existing domains like google.com and your application will then blindly trust these faked certificates too, making man in the middle attacks possible.
I working to develop small HTTPS server that will be included in my android application. And the client will be browser. User can browse to the contain that I have on my HTTPS server. Can someone tell me what kind of setup do I need as far as the certificate and private/public keys are concerned. I am planning to use openssl to create my self-signed certificate.
FYI, I have initial setup done. And since my certificate is self-signed, browser displays warning to accept it on your own risk. So I believe server authentication is working. What do I need for server to authenticate the client ?
Thanks
The problem with hosting an HTTPS webserver on an android device is that the certificates are validated using a domain name. Without a domain name the client browser will display an error unless the server certificate is installed and trusted locally.
The two options are:
Register a domain name, use dynamic dns, and then request an ssl/tls certificate based on that name.
Installing self-signed certificate programmatically
There is an Android library that supports https: http://tjws.sourceforge.net/
What are the best practices for updating client-side SSL certificates without user interaction?
To be more specific:
I have a server with SSL private key/public x.509 certificate.
All clients will communicate with this server through SSL.
In order to establish SSL connection all clients need to import the server's public certificate to their trusted locations (truststore).
Getting the server's certificate at (client) install time is not a problem because the installer can contact the server (by SSL) and get the server's public key (or the company's Root Certificate). After that the installer can show the certificate to the user for visual validation and this is secure enough.
What will happen after the server certificate (or the company CA) expires?
Or what will happen if the server certificate is accidentally changed?
What are the best practices to (automatically) update all clients with the new server SSL certificate (CA)? Having in mind that after installation the clients are background processes and the is not visual user interaction possible.
Of course the easiest way is to manually update all clients by the infrastructure administrator.
I'm wondering if there are some known good practices to automatically update the client's certificates without user intervention?
Ideally, your server certificates should be issued and signed by a trusted root CA certificate with a long lifetime (10 to 20 years). Just the root CA certificate would be installed on the client end.
The server certificate itself, even if you update it every year, would not need to be propogated to clients since the root signed it and is trusted.
If you're using self-signed certificates, this is why they are generally frowned upon from a certificate management perspective. When they expire or change, you need everyone to update - otherwise you'll get browser security warnings.
Was wondering what the best practice for deploying a custom WCF - Security Token Service (STS) in a load balancing environment that uses signs and encrypts the token?
We're using Cirtix NetScaler to handle the load balancing and SSL termination (i.e. certificate is only installed on the NetScaler server). The STS has been specified to sign and encrypt the token via the SigningCertificateName and EncryptionCertificateName app settings. However the current web server configuration does not have a local certificate installed within it's certification store.
So my questions are:-
Do we need to worry about signing and encrypting the token if it's transferred over SSL?
Should we install the certificate on every web server or can we use the load balancer?
Can we use the same certificate on each web server or do we need to buy a certificate for each web server?
An STS which does not sign its tokens is not much use: without a signature, no relying party will be able to distinguish between a valid token issued by the STS and a token spoofed by someone with evil intent.
The certificate you install to support SSL is generally different to the STS's signing certificate. The latter identifies the Service, not the web server. So, by all means carry on installing the SSL certificate just on the load balancer. But you will need another certificate, representing the identity of the Service, installed (with its private key) on each machine which hosts the service, for use as the SigningCertificate. It should be the same certificate on each server (it's the same Service).
However, you typically don't need to buy such a certificate: you can issue your own - you just need to make sure each potential Relying Party is configured to recognise the certificate as a trusted STS, and also trusts the root issuer of the certificate (which will be either the certificate itself, if it is a self-signed certificate, or your root certificate, if you used a certificate server to issue it).
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.