The DCE certification service stores and retrieves "public'' keys. The important characteristic of such keys is that they exist and operate as pairs. Messages encrypted under one of the keys can be decrypted by means of the other (and vice versa); but messages cannot be encrypted and decrypted by means of the same key.
How Public Keys Work: Part 1
How Public Keys Work: Part 2
This asymmetric behavior of the public key-pair makes it ideal for network authentication purposes. One of the keys can be freely publicized in the network, and the other kept secret with, say, a server principal who desires to use it to authenticate itself. The server does this, whenever it is contacted by a prospective client, by simply encrypting a message under its secret key and sending it back to the client. The client then attempts to decrypt the message using the public key it knows belongs to the principal it wishes to contact. If it can decrypt the message, it regards the server as having authenticated itself. The same procedure can be used to authenticate the client (using a different key-pair).
An important detail in the above scenario is that the prospective client "knows'' that the public key it uses to decrypt the server's message really is that server's public key. The other (unmentioned) detail is that the client has to get the public key from somewhere. The secure distribution of the public keys is the job of the DCE certification service.
It is not desirable to have all the public keys indiscriminately accessible to everybody, because then no one will have a reliable criterion for believing whose key is whose. The public keys must be deposited in such a way that users can always be sure that a given public key really "belongs'' to the principal it is supposed to belong to; otherwise entities will be able to impersonate each other simply by switching public keys in the database they are retrieved from. Thus there needs to be some way to make sure that only authorized entities have access to principals' public keys.
The certification service "certifies'' public keys by storing them with "signatures'' generated by the distributors of the keys. The authenticating signatures on certificates are themselves implemented by public/private key pairs. A signature is simply the data of which the certificate consists, encrypted under the issuer's private key. A potential user of the certificate must possess the certificate issuer's public key. The issuer's public key can then be passed (along with the certificate contents, including the signature) to a library routine that will check whether the signature can be successfully decrypted to produce the information in the rest of the certificate. If the signature thus tested is found to be authentic, the user of the certificate can be certain that it was issued by the entity whose public key it checked against the certificate signature - namely, the principal that is supposed to have issued the certificate. The public key signature thus ensures the authenticity of data that can be distributed (and thus easily accessed) via the namespace.
A principal's public key can also be used by entities to protect data being sent to the principal. Data encrypted under the public key can be decrypted only by the possessor of the private key.