The role of digital certificates

A Sybase IQ server must be able to identify itself to clients with its own server certificate. The client must ensure that the certificate is authentic. To do so, the client must already have a trusted copy of the public certificate. Alternatively, the server's certificate may be signed by another certificate. In the latter case, the client must have a reliable copy of the signing certificate.

The Sybase IQ server must have access to its public certificate and to the private key for this certificate. This information is contained in a server identity. A server certificate is constructed by appending the private key to the matching public certificate.

The following figure displays a sample server certificate. This certificate is a server identity, suitable for use by a Sybase IQ server. This particular certificate has been signed by another certificate. The file contains both public certificates and the server's password.

Since other users may have access to the computer running the Sybase IQ server, the file containing the private key is protected by a password. This password is intended to maintain the honesty of the people given access to the computer. It does not provide an adequate barrier to an outside attack as the password is only a few characters in length. To further protect the private key, outsiders must be denied access to the Sybase IQ server by a firewall, or by other traditional means.

Instead of being signed directly by the certificate authority, the server's certificate may be the first certificate in a certificate chain. In this case, the client must trust the owners of all certificates and must have a trusted copy of the final certificate in the chain, called the root certificate. Such a certificate file would have a structure similar to that displayed above, but could contain a longer list of certificates.