Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
typically, you publish your public key to anyone who wants/needs/asks for it. The private key stays, well, secure, on the web server.
The private key can either have an additional security measure to protect itself in case someone copies it (a password), or no password. Having one requires you to be there at service restarts to type in that password. No having one means service restarts happen automatically, but if someone copies the key, anyone can impersonate your web server and decrypt captured conversations.
When you submit your public key to a CA, they are signing your public key with their private one. The CA signed public key is then added to your keystore on the web server.
When a browser client connects to your web server, the public key is transfered in the initial connection. The client checks the trusted CA's signature on the public key of your web server. If the signature is good, and the hostname matches what's on the certificate, everything is grand.
1. client's browser initiates a connection
2. the web server responds and sends its public key
3. the client receives the public key, writes encrypted data with it
4. the client sends the encrypted data back to the web server
5. then the web server decrypts data with its private key
Is this right? So public and private key both reside on the web server?
That basically it. There's a little more too it and I'm not qualified to express at the moment... but basically, the server needs to be able to encrypt the content back to the client. Not sure if it uses a session password (symmetric) or does a browser certificate exchange so then both sides of the conversation are encrypted. I think I'll go read the wiki now...
Both the server's private and public keys reside on the web server.
* In order to generate the session keys used for the secure connection, the client encrypts a random number (RN) with the server's public key (PbK), and sends the result to the server. Only the server can decrypt it (with its private key (PvK)): this is the one fact that makes the keys hidden from third parties, since only the server and the client have access to this data. The client knows PbK and RN, and the server knows PvK and (after decryption of the client's message) RN. A third party may only know PbK, unless PvK has been compromised.
* From the random number, both parties generate key material for encryption and decryption.