private SSL useage

Hi Experts,

I'd like to setup a server at home that contains things like my address book, how do i secure comunication with it via SSL without having to purchase a credential from a company ( like thawte ) that in fact verifies who I am. As i only intend to use it privately I do not need any company to verify me. is there any way tp use SSL without the comerce corupting the internet?

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

You can self-sign your certificates, e.g. as described here:
You can off course set a longer expiry period...
chicagoanCommented: issues free certs for windows

note you should have a host name registered first
If your server at home is genuinely a Windows 2000 or greater server, you can install certificate services from Add/Remove programs and create your own certs.
IT Pros Agree: AI and Machine Learning Key

We’d all like to think our company’s data is well protected, but when you ask IT professionals they admit the data probably is not as safe as it could be.

simply install your own CA, see
OpenSSL - I think we have a winner
There are a couple of ways to securely communicate with your server at home.  One of the most flexible is to set it up with a self signed SSL certificate.  Since you don't need the public to securly access your site, you are right that you do not need your certificate signed by a standard public CA.  See for details on doing this.  

However, if your certificate is not signed by a trusted authority, then each time you access your site, you will be presented with a warning that no trusted path exists to your certificate.  You can choose to ignore this warning, but you run the risk of a man in the middle attack -- i.e., someone hijacks your connection to your server, passing your requests and the responses from the server along (possibly unchanged, but note that he could inject any false or misleading information he wanted), but standing in between and evesdroping on your transactions.  

This is a risk because by accepting an untrusted certificate, you don't actually know that you're encrypting and verifying your transactions with _your_ server's public key.  You could be encrypting to the attacker's public key, sending your information to him, where he decrypts it, reads it, corrupts it or otherwise compromises is, then reencrypts it with your server's key and sends it the rest of the way to your server.  

There are a few solutions.  Since you don't want to pay for a public CA's signature, which gains its security because the CA's certificate is built in to most browsers by default, you'll have to establish trust between your two machines.  

The simplest and most cumbersome method is to verify your certificate's fingerprint or thumbprint each time you use it.  When your browser tells you that the certificate isn't trusted, choose to view the certificate's details.  Depending on your browser, there are two hashes that you might see -- they're called finger or thumb prints.  Compare these to the values you get by computing the finger/thumbprints while sitting at your server, and if they match, it's ok to accept the certificate.  

See for a list of common SSL commands, including for getting fingerprints.  

Once you've done this, you can choose to "install" the certificate -- that way, your browser remembers the certificate and you won't have to check the fingerprint each time you use the site.  

With this solution, you can then consistently and safely use your work computer to access your home page.  However, you'll have to check the fingerprint again for each computer you use to access the site.  

If you plan to run several sites this way, you can setup your own unofficial CA, install that CA's certificate in your browsers, then sign your server certificates with your CA's key.  This is essentially the same technique, but allows you to expand more readily.  See for information on this.  

However, in my experience, messing about with SSL causes headaches.  I _do_ run one of my servers this way, but it's annoying.  SSL has the great advantage of allowing websites with certificates signed by the public CAs to communicate securely with millions of people, but SSL is tricky to learn and use, and can easily be messed up.  Also, checking the fingerprints of non-publically-signed certificates is tedious, and skipping the check since it's such a bother can lead to security risks.  

Therefore, when the issue came up for me again, I decided to postpone the SSL technique until I had time to mess around with it, and instead used a combination of .htaccess files and SSH to securely tunnel to my site.  This interim solution worked so well that I still use it.  These directions are geared towards Apache with .htaccess files, but I'm sure you can adapt them to other servers.  

Here's what I mean:

1. Restrict access to the pages/directories you want to protect to "localhost" using .htaccess files.  Here's an example .htaccess file:

        <limit GET POST PUT>
        order deny,allow
        deny from all
        allow from

You can also do .htaccess Basic Authentication here, which should be pretty secure, since we're going to encrypt our sessions with the server.  See for an excellent .htaccess guide.  

2. I'm assuming you're using *NIX, but if not, you can still do this step by installing Cygwin on Windows and running an SSH daemon as a service.  I do it on XP, but it's a bit involved to set up.  Check out google for tips on that one.  You can also see below about running the web server and ssh daemon on different boxes.  

Now, if you have a *NIX system, odds are you're running sshd or can easily do so.  To connect to your machine, just tunnel a port from your local (work) machine to port 80 on your webserver.  Here's the command:

ssh -L 4321:localhost:80

You can also use putty or whatever SSH client you'd like to use.  If you use the version, you can do all this through the GUI settings under Edit Profiles, on the Tunneling tab.
If this is your first time connecting to your server from any given machine, I strongly reccommend that you verify your server's (SSH) public key fingerprint against the fingerprint you got by running ssh-keygen -l (that's an L) on your server.  ssh-keygen -B may also be useful, since this gives "bubble-babble", which is how's client presents fingerprints.  This is equivalent to checking your SSL certificate's fingerprint in terms of security ramifications.  Once the fingerprints match up, install the server's key.  

Assuming all this has worked out, you've now established a secure, encrypted tunnel between your work computer at port 4321 and your home server at port 80.  

3. To connect to the website, just point your browser at http://localhost:4321.  You've now got a secure link to your server, sans SSL or any special webserver settings.  Just be sure not to break the connection by using absolute URLs in links or anything...  This sounds bad, but you still would have had to make sure all your links pointed to the https:// version of your site if you were using SSL.  

1. restrict access to localhost (i.e. your server)
2. tunnel to your server using SSH
3. access http://localhost:port

This is equivalent to SSL but for me it's cleaner and easier.  It separates the encryption from the quirky and "user friendly" web browsers, and should, if done right, be just as secure.  

One final thought.  If you don't want to or can't run sshd on the webserver, you can run it on a local machine on your home network.  Then just restrict access to the page to that machine on your LAN, and tunnel to the webserver through the LAN machine running sshd by using ssh -L 4321:yourwebserversLANaddress:80  This ought to be ok, since I assume no one's tapping into your LAN.... just don't do this if you use a wireless LAN, or if you bridge your LAN into your local cable provider's network.  

Good luck.  

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Two words:
I think that's five words...
FouadDanielsAuthor Commented:
I appologise it took so long, thanks for your effort. it has helped me alot eventually.

Once more sorry that only now I came back on this subject.


Fouad Daniels
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.