Find the answer to your Linux question:
Results 1 to 2 of 2
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    Newbie Qs: Simple SSL setup 2 secure comm (& other thing


    I'm looking for the least-intrusive way for a user (as in a web-browser client user) to access a "secure" server in order to fulfill these goals:

    1) Establish secure communication between web server and web client (so that a 3rd party can not, among other things, steal login/password and other sensitive info provided by either the server or client).
    2) Enable the server to authenticate clients via login/password and possibly via client IP num/range.
    3) Enabled the server to authenticate clients by a means of a distributed "key" (possibly with something like managed SSL-client certificates).
    4) Enable the client to authenticate that the server is who it claims to be (such that a "Trojan Horse" won't steal login/passwords, etc).

    In the documentation I've read thus far, the SSL/Apache community seems rather fixated on #4. While I suspect this is quite important, it's *last* on my list. When trying to setup capability for #1, I am seemingly forced to deal with all the stuff associated with #4 (if I want to try and hide popup/warning msgs at my user's client browsers, anyway).

    Why? Why not clearly separate the 2 mechanisms? Maybe I simply misunderstand and do not know how to do so?

    I have a few more comments and questions below.

    More Details

    I am new to SSL and Apache web-server management, and I've been browsing various doc sources.

    I want a means to securely the communication from my web servers to my clients (and vice versa) such that a 3rd party can not snoop/steal info from said communication. A popular means to do this seems to be: 1) use public/private key SSL-based encryption to provide a secure communications channel, and 2) use Apache authentication mechanisms (like htpasswd, IP num/range checks, etc).

    I also want to do this in such a way that my users have the least-intrusive and "comfortable" experience possible. Read: I don't want to see the "Website Certified by an Unknown Authority" popup window (that occurs in my Firefox 1.0PR browser); I just want to connect to my server via my browser and get an instant, secure, "https:"-based communication, no fuss, no muss.

    So, first big question: can I do this without having to get a formal certification from CA? suggests that maybe I can. Alas, if not, I'm still wondering why the development community decided to mix up my goal #1 (above) with my goal #4. I see many server managers and client users who care a lot about #1 and very little about #4 (even though possibly they should?).

    [An aside: It seems rather difficult to spoof a server. The only way I can think to do it is to put a rouge DNS server out on the net that remaps my server name(s) to an "evil", Trojan-horse-type server that will try suck down the authentication login/passwds for my legitimate server. Also, maybe one can "copy" the IP address and try to use it for their server, although this 2nd method seems less reliable and much more easily discoverable by me. Bottom line: do I legitimately need be concerned about server impersonation? Maybe I simply do not understand what's going on in this realm?]

    The means to fulfill goal #2 above seems well documented, thorough, and cleanly implemented.

    2nd Q: Even if I do get a CA cert and build in the appropriate keys/configuration on my server, will a client still see these "popup" windows?

    I'm curious because I can see that my logins to places such as and other things have secured, "https:", connections, but I for the life of me never remember having to "verify" Etrade's server identity via a browser popup window. Do they have some magic that I can easily use on my server(s)?

    3rq Q: As for the client-authentication: It seems like SSL-client-key-certification is a good if not "best" route for this for beyond "login/passwd" or "IP-address-based" authentication; in other words an authentication mechanism that's tougher for someone to "steal". (Would any care to add comments?) The most-important part of this Q: I want to develop the "simplest" means for a user to do this (even if I have to do some significant work to set this up). I envision emailing a SSL-cert file "key" and simple browser-file-key-import instructions to each user; even better, it would be nice if I could provide a program that once executed will automatically install the client certificate on the user's computer/browser automatically so that said user can be verified on their next attempt to login to my secure server. Regardless, can anyone provide guides/pointers/recommendations/RTFM points?

    That's all the questions I can think of for now. Thanks for reading thus far!


  2. #2
    Linux Guru kkubasik's Avatar
    Join Date
    Mar 2004
    Lat: 39:03:51N Lon: 77:14:37W
    this is a quikie reply, but I will try to be back later to address this more fully. basicaly, #1 and #4 are basicaly going hand in hand, the only way to accomplish number 1 would be to pretend to be someting your not (#4) and get the client to send all thier information htrough you first, whitch you would then pass onto the server, so they would continue to send information. Basicaly a security certificate states name IP and other essentials about the server, in a addition to the key needed to break the encryption. This is sent to the client, some web clients will automaticaly accept certificates from certian vendor etc, but you can configure your client to trust a certain certificate if so required. If you basicaly want to create a secure connection between your apache powered webserver and your client, mod_ssl and create your own certificate (I believe that openssl, whitch you must install in order to use mod_ssl, has a integrated script for this)
    Avoid the Gates of Hell. Use Linux
    A Penny for your Thoughts

    Formerly Known as qub333

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts