> One of the hurdles to get over when setting up a system is that the > first time a user connects to the user portal with a browser, they get > a > (deliberately) scary warning from the browser that the certificate from > the server is unknown and unverifiable and therefor this may be a bad > server you should not connect to. The user has to go through a process > to suppress that warning on subsequent connects. The process varies > depending on the browser, but isn't that obvious and seems to be > getting > more complex with each upgrade as browsers try to tighten up security. > This whole process puts people off (it's supposed to) and that's a bad > thing for us (you only get one chance to make a first impression, and > this isn't a very good place to start). > > So ... what causes the warning, and what can we do about it? > > You get a warning when you connect your browser using https to a server > that has a certificate your browser cannot validate. The main way this > happens (when it's not just a bug) is when your browser cannot verify > the signature on the server certificate because the browser does not > have the public key of the CA cert that signed it. > > Browsers come with a large collection of publicly known CAs (in > Firefox, > Edit->Preferences->Advanced->View Certificates->Authorities). To avoid > browser warnings with no user action, you need to derive the > certificate > for your server directly or indirectly from one of those. > > Larger organizations can and do set up their own CAs - either by > building the infrastructure themselves or by contracting for it from > one > of the commercial CAs. When they load PCs, they install the > organizations CA certificates into those PCs (and usually also load a > client certificate signed by that CA with its private key into the PC > for authorization purposes). For these, we can avoid warnings by > providing the means to get the server a web certificate signed by the > private CA - the new screens Mircea has been adding. In these cases, > users won't get the scary warnings, so there's no problem, but these > cases are not common in smaller organizations. > > So what can we do for users that don't have a private CA and don't want > to spend $$ (every year!) to get a commercial certificate from one of > the well-known CAs for their server? > > We've normally got an email address for each user; when a new user is > created, we could send them a Welcome email. That email could provide > the user with the details of the new account: this is your extension > and > your initial PIN, here is the link to your user portal, here's the > quick > reference guide to the system, etc... and include in that email either > of two things: a copy of the CA certificate to be loaded into the > browser (research project: is there a way to package a cert that would > trigger this easily?), or at least an explanation of the fact that the > warning will happen and how to suppress it (including the key > fingerprint data so that users who understand it can do the right thing > and verify the key). We could even have the setup script do the same > thing for the administrator (which would only work if the system was > connected to the network when the server was set up, but wouldn't hurt > otherwise). >
Not sure providing a cert loading mechanism in the user portal would be a good idea. Very complex and not something for the average joe. Isn't it safe to say we already have a way today for people to get rid of the nag messages? Aren't certs like 20-30 bucks a year? Seems like a reasonable option that we already have in place. > > > > _______________________________________________ > sipx-dev mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
