Disciplina Networks is very security conscious, and, as a result we go to exceptional lengths to ensure that any sensitive information is encrypted. The most widely recognised form of encryption for traffic on the Internet is SSL. In order for any traffic to be encrypted with SSL, there needs to be certificates generated and accepted by both parties. To this end Disciplina Networks runs it own Certificate Authority. This allows us to issue certificates for each service that we run and, if requested, for each of our users. There are some problems with using SSL. The most notable problem is that most applications are not very careful with how they support SSL. Let me explain. Due to the popularity of SSL almost every application that might have sensitive data can now support SSL, however, almost all implementations don't give the ability for a user to accept "invalid" certificates. What are these certificates and why would we want to accept them anyway? Invalid certificates are any certificates that can not be verified according to a master certificate stored on the client computer. Given that very few applications actually come with a set of master trusted certificates this poses a problem, how do we get this list and who should we trust? Most users are, unfortunately, Windows users in current times, and the way Microsoft has gotten around this problem is by providing a list of master certificates with the Operating System itself. The certificates trusted are from the "recognised" trusted certificate authorities and signers which basically equates to Verisign and Thawte. Now in addition to providing a set of trusted certificates Microsoft provided an API for applications to access them (this is a good things that Free software applications have copied, look at kde for an example) with the result that end users didn't have to install certificates. Ofcourse, this is only true when users use applications (in the case of SSL the most common "application" is browsing SSL protected web pages, ie HTTPS) that the remote end has a signed certificate from a "recognised" vendor. If they don't then applications SHOULD prompt you to accept the certificate anyway, but after warning you of what you are doing. While browsers do this, many other applications don't, and this is where the problems start. What happens if your application doesn't let you accept certificates that are not signed by a "recognised" authority? Well, the secure default is to deny access and consequently it "fails" to connect. The issue with that is that there are a surprising amount of applications that have not been written to deal with this common situation, Microsoft has spoiled them by supplying a default list of common Certificate Authorities and as a result many application writers are unaware that it is possible to have a certificate that you might want to use, but that isn't in your master list. To get around this problem, what we must do is install a "master" certificate for the Disciplina Networks. How you do this varies from Operating System to Operating System, and from application to application. In general there should be specific instructions for any application, although this is often ignored in windows only applications due to using the crypto API. Disciplina Networks master certificate can be found here. The best advice we can give you on installing this certificate is to read the manual that comes with whatever SSL enabled application you are trying to use. As a general guide, if you are using Windows, you can install a certificate via the options menu in the Internet Explorer properties tab. If you are a Disciplina Networks user, and are having issues installing a certificate, please contact me and I will endeavour to help you where I am able. strerror