Using Samba Robert Eckstein, David Collier-Brown, Peter Kelly 1st Edition November 1999 1-56592-449-5, Order Number: 4495 416 pages, $34.95 Buy the hardcopy Table of Contents

Appendix A

 

---

A. Configuring Samba with SSL

Contents:
About Certificates
Requirements
Installing SSLeay
Setting Up SSL Proxy
SSL Configuration Options

This appendix describes how to set up Samba to use secure connections between the Samba server and its clients. The protocol used here is Netscape's Secure Sockets Layer (SSL). For this example, we will establish a secure connection between a Samba server and a Windows NT workstation.

Before we begin, we will assume that you are familiar with the fundamentals of public-key cryptography and X.509 certificates. If not, we highly recommend Bruce Schneier's Applied Cryptography, 2nd Edition (Wiley) as the premiere source for learning the many secret faces of cryptography.

If you would like more information on Samba and SSL, be sure to look at the document SSLeay.txt in the docs/textdocs directory of the Samba distribution, which is the basis for this appendix.

A.1 About Certificates

Here are a few quick questions and answers from the SSLeay.txt file in the Samba documentation, regarding the benefits of SSL and certificates. This text was written by Christian Starkjohann for the Samba projects.

A.1.1 What is a Certificate?

A certifcate is issued by an issuer, usually a Certification Authority (CA), who confirms something by issuing the certificate. The subject of this confirmation depends on the CA's policy. CAs for secure web servers (used for shopping malls, etc.) usually attest only that the given public key belongs the given domain name. Company-wide CAs might attest that you are an employee of the company, that you have permissions to use a server, and so on.

A.1.2 What is an X.509 certificate, technically?

Technically, the certificate is a block of data signed by the certificate issuer (the CA). The relevant fields are:

• Unique identifier (name) of the certificate issuer

• Time range during which the certificate is valid

• Unique identifier (name) of the certified object

• Public key of the certified object

• The issuer's signature over all the above

If this certificate is to be verified, the verifier must have a table of the names and public keys of trusted CAs. For simplicity, these tables should list certificates issued by the respective CAs for themselves (self-signed certificates).

A.1.3 What are the implications of this certificate structure?

Four implications follow:

• Because the certificate contains the subjects's public key, the certificate and the private key together are all that is needed to encrypt and decrypt.

• To verify certificates, you need the certificates of all CAs you trust.

• The simplest form of a dummy-certificate is one that is signed by the subject.

• A CA is needed. The client can't simply issue local certificates for servers it trusts because the server determines which certificate it presents.

---

9.3 Extra Resources		A.2 Requirements

---