Advanced Topics

What is X.509?

X.509 is the mainstream Public Key Infrastructure or PKI. It's a huge, complicated beast, and a detailed description of it would be much longer than we can fit in here. However, it's a big part of Checkpoint 6, so we'll try to give you a reasonable precis.

Why do I need a PKI?

Suppose you need to communicate securely with some other entity across the Internet, eg. a Checkpoint service running on another machine. How might you go about it?

Well, if you could somehow arrange, in advance, a shared secret (a password) which you know, and the service knows, but nobody else does, then you could use conventional, symmetric cryptography (the kind which is used to encrypt CDBs) to secure the link. Unfortunately, that's not very practical.

Next we have asymmetric or public-key cryptography. For this, each party (yourself and the service, to continue the example) has two different keys. One key is public, the other private. However, these are related mathematically, and have two useful properties: firstly, you can use the public key to encrypt a message such that it can only be decrypted with the corresponding private key (and not with the public key); and secondly, you can't determine the private key even if you know the public one. Therefore, if you know the service's public key, you can send it a one-off shared secret [more-or-less - it's more complicated in practice, but the idea's the important thing here] and set up a secure link that way.

So far, so good. However, there's a problem: how do you get hold of the service's public key? Well, you could just ask. Unfortunately, there are various ways that an industrious attacker could subvert this process; we need cryptographic assurance that the public key belongs to the party we have been told it does, and not to some impersonator.

To solve this, we turn to another trick which asymmetric cryptography has up its sleeve, called digital signing. What this means is that one party can use their private key to create a digital signature for some piece of data, which any other party who knows the corresponding public key can verify. If the data is altered in any way, the verification process will fail.

This brings us to the idea of a digital certificate. This consists of:

• A distinguished name;
• A public key, for which the corresponding private key is controlled by the rightful owner of the DN;
• copious amounts of housekeeping data and other red tape, which we don't need to care about here;
• all bound together by a digital signature.

This, finally, is where the whole PKI comes in. A group of industry worthies have caused to be widely distributed a range of these certificates, each of which is signed by the (private key corresponding to) the public key on the certificate itself. These self-signed root certificates ship with browsers, the Java VM which Checkpoint runs in, etc. The idea is that if you want to get into this secure-communication business, you do the following:

1. Generate a keypair (a public key and the private key which goes with it).
2. Send the public key, the DN, and some evidence that you own same, to one of the said worthies.
3. The worthy (Certificate Authority, or CA, as they like to be called) will generate a certificate and sign it (after your payment has cleared), thus attesting that this is, indeed, your public key.

[NOTE] Astute readers will probably have noticed several large holes in this scheme. We know. However, in practice it seems to work anyway.

How does it work?

The idea is that, when you contact a service, the service will present you with its certificate chain. This consists of its own certificate (which contains its DNS name), the certificate of the CA which signed same, and so on until the last certificate in the chain, which is a self-signed root certificate. However, you've already got the root certificate (it came with your browser) so you can verify the entire chain.

After you've gone through this part successfully, you know that the service is genuine. However, the service doesn't know anything about you; you still need to authenticate yourself to it.

Normally this is done via some conventional authentication process; eg. DN and password. However, if you're feeling keen (and / or can't be bothered with typing in passwords all the time) you can reply by presenting your own certificate chain to the service. It does the same thing, and in the end it knows who you are, just as you know who it is.

All of this requires that the service be using the standard TLS (also known as SSL) security layer. All major browsers support this. As well as the X.509 authentication described here, TLS also provides confidentiality (data on the wire is encrypted and can't be eavesdropped) and data authenticity (data can't be altered without this being noticed). Contrary to popular opinion, the latter is usually more important than the former.

How does Checkpoint help?

Checkpoint and CPCC provides the certificate lifecycle management tools which are needed to make use of X.509, in a clean and easy-to-use manner. All of these tools use the well-known, standard formats, and should be compatible with most third-party applications. These formats are usually called "PKCS#n" (where 'n' is a number), after the set of standards documents which define them. Don't worry unduly about which number is which.

Certificate generation

Generates a public / private keypair, and a self-signed certificate to keep the public key in. Checkpoint generates keys for the RSA algorithm; this is well-known, flexible and unencumbered by patents.

Certification request

The self-signed certificate won't be much good on its own unless you intend to become a CA in your own right; you need to get your certificate signed by a CA which is trusted by other parties. [In fact, the CA will issue a new certificate which includes your public key and DN; this replaces your temporary certificate en bloc.] This option generates the request which must be sent to the CA. The format is signed, so it's tamper-evident and does not need to be sent over a secure channel.

Certificate import / export

Export or import a certificate or certificate chain. If you've decided to be a CA, you'll need to export your self-signed certificate so that you can give it to all your clients.

Keypair import / export

Export both the certificate chain and the private key which goes with it. If you want to use a personal certificate to access remote Checkpoint services via your browser (the usual route) you'll need to export these from Checkpoint in order to import them into your browser. This file must be encrypted; options for setting the required password are provided.

Trusted CA import / selection

If this copy of Checkpoint is running services, and you want to allow users to login using X.509 certificates (recommended), then you will need to define the set of CA certificates you want to trust to vouch for those certificates. By default, browsers trust a wide range of CAs for the sake of maximising interoperability. However, we decided that it was more important to ensure that some thought goes into what is actually a fairly important question of security policy, so by default Checkpoint does not trust any. [This feature is located under Host configuration.]

TLS "glue"

Finally (and of more significance to developers than end-users), Checkpoint provides the required "glue code" to make it easy for Checkpoint Applications to use TLS for any kind of network traffic.

The one function which is not supplied by Checkpoint is the ability to act as your own CA: you can generate a CA certificate but the actual certificate-signing operation is not available as part of the Checkpoint Core. If you want to do this, you need Checkpoint COBRA, our addon product.

General

This section covers various twinges you may encounter.

Browser effects

Some browser settings can cause problems.

• Overenthusiastic caching. CPCC pages should never be cached by your browser (they're dynamic, and change unpredictably) and the HTTP headers (which aren't part of the page, but are supposed to be obeyed by the browser anyway) say "don't cache me" in several different dialects! Nevertheless, a few browsers may not obey this. If you think you're running into this, try to force your browser to reload; if this clears the problem, then either try to turn off the cache in whatever way your browser does this, or try a better browser.
• Smart-alec MIME typing. The MIME type of a page tells the browser what to do with it - render it as a page, save it to disk, hand it off to a video player, etc. CPCC tells the browser what the right MIME type is, but some browsers may ignore this and try to guess instead. Since some of the pages don't have the normal extensions, this tends to go wrong. Typically this is what's happening if the browser brings up a "save as..." dialog rather than displaying the page you were expecting. If you get this, tell the browser not to do this; again, how you do this depends on what browser you're running.
• Some browsers offer to remember your password for you. This is undoubtedly convenient, but be cautious - some implementations are horribly insecure. How is the browser's password cache guarded?

Malignant login tasks

Sometimes you set a login task, but the login task isn't working properly, and won't take you back to the front desk (so you can't disable it while you work out what went wrong). Here's how you get out of it:

1. Look at the URL of whatever page your login task is giving you. The chances are it'll look something like:

   http://localhost:33430/i13/42/dyn/foo/garble.html

2. take out the first /i13 (the number after the 'i' will probably be different, and may well be 0).
3. Keep the following '/' and the number that follows it (here, 42).
4. Replace the rest with /dyn/front.html . Thus the URL shown above would be replaced with

   http://localhost:33430/42/dyn/front.html

This URL should take you to the front desk.

If that doesn't work, you can set a special flag which disables login tasks for the subsystem owner. To do this, shut down CPCC and edit cpcc.boot as described in "Chrome hacking" above, but this time add the line:

-Dccs.cpcc.noSubsysOwnerLoginTasks

exactly as written, instead.

Forgotten passwords

As a responsible host owner, it is incumbent upon you not to do something as pathetic as forgetting your own password - if anybody else does this, then another user who has the manage-users privilege can change it for them, but your account is protected, and so they can't (if, as is quite likely, there is only one host owner).

However, if you do manage this one - to be fair, most of us have done it once or twice! - here's how you recover.

1. When you first installed Checkpoint, the ConfigureMage made you save a copy of the root database password. You need to find this. If you've changed the password since, the tool made you save a copy of the updated version; you'll need to find this instead. If you've lost it, you're out of luck.
2. Shut down all Checkpoint applications, and the Checkpoint Daemon if it's running (it's called checkpoint.exe in Windows).
3. Make sure you have a good backup of the Checkpoint installation. This procedure is potentially dangerous!
4. Start the Checkpoint Daemon, but supply the following extra command-line parameters:
   
   -backdoor <rootPwdPath> <dn> <password>
   • <rootPwdPath> - the path to the root password file described in step 1.
   • <dn> - the DN to restore. This will receive all available permissions.
   • <password> - the password for the restored DN. This will not have a token.

If your installation does not allow tokenless logins, you will have to relax this restriction temporarily while you recover. You can do this as follows.

1. Shut down any Checkpoint applications which are running, and the Checkpoint Daemon.
2. Where necessary, become the Checkpoint system user. If you don't understand this, it probably doesn't apply to you.
3. In the lib subfolder of the Checkpoint installation, rename the existing shadow.cdb to shadow.cdb.real or some other suitable name.
4. Start CPCC. The ConfigureMage process will start.
5. Perform the first step of the ConfigureMage process to create a null token. Then shut down CPCC and close the browser window. Don't perform the rest of the ConfigureMage process!
6. Stop the Checkpoint Daemon again.
7. Rename shadow.cdb.real back to shadow.cdb.
8. Restart the Daemon (if you normally need to start the Daemon manually) and CPCC. You should now be able to login as normal using the new password.