Setting up a dedicated PGP certification server
Introduction
The settings here is chosen to make it work smoothly, without reducing the security level. However, the customer will most probably like to modify them after having gained experience after the pilot project. Therefore the customer must be present the first time, so he later can redo it himself.
Status of this document.
Required software.
Required by customers network
Order of installation.
Install Windows NT 4 server, with service pack 3. Reformat the hard disk to avoid old garbage. Use NTFS file system to take advantage of NT:s built in security. When the installation asks for:
Windows NT Setup: <Next>
Name and Organisation: (fill in)
Registration: 040-1234567 (a cheating number if the real number is not avalible)
Licensing modes, tick "per seat" and set the amount of concurrent connections to, say, 500. I do not know what happens if too few connections are specified, so therefore we do not want to take a chance. Licensing question is outside the scope of this document.
Computername: certserver (the name certserver can be chosen to adhere to established praxis. But feel free to use any other name)
Servertype: Stand-alone Server, in case you do not have the local system administrator available to ask for his preferences.
Administrator account: (enter a root password)
Emergency Repair Disk: (Yes, if you have a diskett avalible, otherwise it can be created later)
Select components: (Next, accept the default selection)
This computer will participate in a network, and is Wired to the network
Install Microsoft Internet Information Server (use IIS (as a web server) in order to remotely control the certificate server.)
Search for a network card <next>
Network Protocol: You do only need TCP/IP, unclick the rest just to save space and reduce problems
Network Services: <next> accept default, including Microsoft Internet Information Server 2.0
TCP/IP setup: Select a DHCP server, that's the normal method today, since there is a lack of fixed IP-numbers.
Windows NT Server Setup: Enable all three components, and press <next>
Select domain: Add the domain, where the certificate server will be. For example, qainfo.se
Microsoft Internet Information server 2.0 setup: You can unclick installing gopher and ftp services, since these will not be used, and there is no benefit of installing more than necessary.
Install drivers: Install SQL Server. (It might not be needed, but fine tuning is a later step)
Select proper Timezone, and date/time
Select a videomode that corresponds to 800 x 600 pixels, for best viewing the configuration screen with the browser.
Install Microsoft Service pack 3. This will upgrade Microsoft Internet Information server from version 2.0, to version 3.0.
Start the WWW-server by "Start->Programs -> Microsoft Internet Server -> Internet Service Manager" Make sure it is marked as running
Doublecheck that these three mappings exists:
C:\InetPub\wwwroot -> <Home> Must always exists
C:\InetPub\Scripts -> /Scripts
C:\WINSRV\System32\inetsrv\iisadmin -> /iisadmin
Upgrade to a never version of webreader than 2.0!
Reason: The default webreader (Internet Explorer, ver 2.0) is known to crash during configuration of PGP's certificate server. Install a never webreader. Netscape's Navigator 4.04 and Internet Explorer 4.01, with it's service pack 1 and Opera, 3.5.1 is known to work. A minimal installation is enough for this purpose.
--- end of installation of Windows NT 4 server ---
Step 2)
Step 3) Configuring the client version.
Let the user create the administrative keys.
Create at least these two administrative keys:
The corporate signature key. In a small group, it certifies all employees. Another common method is to instead let this key certify trusted introducers, which in their turn certify their group members. This hierarchical model is better suited for corporations than the web of trust. It is typically used in a larger group, or several groups, which is geographically spread out. There is one assigned trusted introducer for each location.
The revocation key. Allows the corporation to revoke keys if the user has forgotten his password.
If data recovery is wanted, create these recovery keys for: Outgoing email, incoming email, and PGPdisk for locally stored data.
Out Mail Recovery
In Mail Recovery
PGPdisk Recovery
The result is that a total of five keys are now created. A suggestion is to use these names. The customer will probably create new key at a later stage, in any way. It is a good practice to assign a sequence number for each key. When they are replaced at a later stage, it is easy to differentiate between old and new administrative keys. The next creation of keys will thus be assigned the number 1, 2, 3, etc.
Signature key 0
Revocation key 0
Out Mail Recovery 0
In Mail Recovery 0
PGPdisk Recovery 0
Set the signature key as the default key, and sign the other administrative keys so there is a certificate chain.
Step 4. Creating/distributing the client version.
Improving search speed by setting proper search order.
In the PGP-program, add the domain name of your new certificate server. Like ldap://certserver.qainfo.se, and remove certificate servers that are known to not be used. For example, closed groups, such as banks, have no use of Internet's public certificate servers. In other situations, they are wanted, but the client software should first search on the corporation's own certificate server. This means that we have to change the search order when PGP is requesting updates, or verifications of the local keys against the certificate servers..
The default search order is:
ldap://certserver.pgp.com
http:// pgpkeys.mit.edu:11371
<corporations own certificate server>
When an update is requested for keys on our local keyring, it will first be searched on two certificate servers on Internet, before it's found on the corporation's certificate server. This takes time, so therefore we want the corporation's certificate server to be in the top of the list, and searched first. Write down the adressdetails about the certificate servers that you want to be search last, and then delete them. The corporations own certificate server is now alone and at the top of the list. Add the two certificate servers we just deleted, to correctly set the search order. The result is:
<corporations own certificate server> (search this one first)
ldap://certserver.pgp.com (Then search this server)
http:// pgpkeys.mit.edu:11371 (search this one last)
Defining the user preferences.
Tick the boxes:
PGPKeys ->Edit -> Preferences -> General-> "Always encrypt to default key" (so sender can read he's sent mail)
PGPKeys ->Edit -> Preferences -> Email-> "Automatically decrypt messages/verify when opening messages". (for convenience)
PGPKeys ->Edit -> Preferences -> Email-> "Sign new messages by default"
PGPKeys ->Edit -> Preferences -> Advanced-> "treat marginally valid keys as invalid" (we are not using the web of trust in corporate environment)
PGPKeys ->Edit -> Preferences -> Servers-> Synchronize with servers upon -> tick all boxes for highest security. (It is better to start from highest security level, and then reduce it according to the actual need, than open all doors, and close them later.)
Remove unnecessary keys.
By default, three keys are by default added to the keyring. Two are from NAI, and one is from Cnlab. These three keys can be deleted from the distribution of the client version to the end users (since the end user has no use of these keys) It is only the IT-department that will be responsible for verifying new software versions before distributing it, so its only they who needs these three keys.
To conform with the default place of keyrings, doublecheck that the keyrings are at;
C:\Program Files\Network Associates\PGP60\ PGP Keyrings\pubring.pkr (the public keyring)
C:\Program Files\Network Associates\PGP60\PGP Keyrings\secring.skr (the private keyring)
Start PGPadmin.exe that will create the client version. Let the customer do all the work, and explain screen by screen, what is happening, and how a certain choice is recommended according to his security demands, that you have been told in step 2. For example, some customers do not want the end user to be able to use conventional encryption, because it is yet another unnecessary tickbox for the end user, or it is considered as a security problem for those who want to use data recovery. Others don’t care. If an employee want to send a secret love letter, let them do so.
In the last step of this phase, a screen shows all selections that the customer has done in the policy. Use cut & paste to copy this information to a ordinary text file. It is a part of the documentation.
Distributing the client version.
This is easiest done by placing it on a fileserver which everybody in the pilot project has read access to. The distribution is then done by having the end user to click on setup, in that directory.
Step 5. Installing the certificate server.
A note on ver 1.0 of the certificate server.
"--------------------------------------
Error!
Certificate Server validation of configuration file failed:
Locking file (C:\Program Files\PGP\PGPcertd\data\.lockfile) failed with error 33: The process cannot access the file because another process has locked a portion of the file. Database may already be locked by another server. Configuration data available in C:\pgpcertd.64.
Last Generated Tuesday, January 26, 1999 14:49:48 "
Solution: If you do not need compatibility with RSA-keys, upgrade to ver 1.0.2
---
Start the installation, setup.exe
Select components (accept default, which is all components)
Question: "Setup has determined that you have Microsoft Internet Information Server (IIS) Installed. … Do you want setup to do this for you? Answer Yes.
Security Alert. Enabling this option allows anyone with a web browser to … access this server. Do you want to continue? Answer Yes. This is a quick installation. The art of protecting the certificate server from unauthorized use, is a later step. One easy temporary solution is to pull out the network cable during installation.
The certificate server has now added these mappings of three directories. Double check with:
Start -> programs ->Microsoft Internet Information Server -> Internet Service Manager. Right click on the www server, and the tab; Directories.
C:\Program Files\Network Associates\PGPcertd\docs -> /certserver/docs
C:\Program Files\Network Associates\PGPcertd\web\cgi-bin -> /certserver/cgi-bin
C:\Program Files\Network Associates\PGPcertd\web\htdocs -> /certserver/htdocs
If these do not appear, the web server must be halted and then restarted again in order to make the mappings to be readed in, and interpreted,
---
Microsoft's instructions for the their Service pack 3 says that it should be installed after each modification, so if you want to follow the schoolbook, reinstall servicepack 3. However, I have not encountered any problems by not doing it.
Start the certification server by:
Programs ->PGP Certificate Server -> PGP Certificate Server,
and tick the box "Create Database" and then press the Start button. The response should be "The database was successfully created"
Tick the box "Check configuration" and then press the start button again. The response should be "The configuration is correct"
Start the certificate server from the program menu, by pressing start again. There should be an indication in the blue bar at the top;
In Ver 1.02, it says "PGPcertd (running-389)" The number, 389, indicates that the certificate server use (listens on) the default port for the LDAP protocol.
[In Ver 2.0 it says "PGPcertd (running-389:disabled)" The word disabled means that the server is currently not using encryption for adding/retrieving keys.]
Note; your firewall must opened for port 389
Configuring the certificate server from a web reader.
Start the installed webreader, and surf to http://localhost/certserver just to verify that our local webserver is up and running. You should see a webpage which says "Welcome to the PGP certificate server"
Done. The certificate server is now up and running with it's default settings. Which means that nobody has access to the database, and thus we can not yet add any keys there.
Click on the webpage's Configuration Wizard. Accept default, and click on next. You will then see "current status"
Click on the Configuration icon at the top of the screen
[Ver 2.0. Go down a few screen to "Secure Mode" and click on disable. We will enable it again later.]
Go down to the button; "Allow access by" and click on "new". Add a star "*" (wildcard) in the field "allow access by".
[ver 2.0. More keys are added]
Click on "Submit" and we will automatically return to previous screen. Go down to the bottom; "Allow access by:" and click on "Update Server" The screen should tell us that the configuration was successfully updated. Restart the certification server, so it rereads the new configuration.
The configuration file; PGPcertd.cfg, which now has been created in the server, is part of the documentation.
Now, start PGP and send keys to the keyserver, to verify that all works.
This is the configuration that is used by the public key servers on Internet. It means that we now have opened the server to any IP-address, and allowed everybody to add keys, without any restrictions. It is a good test to check that everything works fine. However, corporations usually want a more closed key server that contains only their own employee's keys. We will later add the corporations signature key that was created before, and then we will close this wide-open configuration.
6) Installing a client version.
Retrieve keys from the certificate server. Note that all keys have gray icons in the Validity-field. This means that the users program does not trust them.
Create a test key pair. Make it as the default key. Note that the icons in the validity field now turn green, which means that the users program now trusts them.
Explanation: This is due to the fact that whenever a user creates a key, PGP do by with our configuration, also signs the corporate key as something termed meta-introducer. This means that the users program automatically assigns trust to whatever key that is signed by the corporate signature key.
Upload the testkey to the certificate server, just to ensure that it works fine.
The basic installation is done. We have a running system.
7) Fine tuning the certification server.
Note. To change the security policy, or other settings, create a new client version with pgpadmin.exe, and have all users to reinstall the software to all users. One of the goals for a pilot project is thus to establish security rules that are so stable that they hopefully, will not require any changes.
Rejecting unauthorized keys.
One common security policy is to only allow keys that are signed by the corporate signature key, to be uploaded to the server. This is the distinct contrast to the public keyservers on Internet, where everybody is allowed to add keys to the servers.
A Corporation normally wants to only maintain their own keys, and let the public key servers on Internet be the storage area for all other keys from the public. There are two ways to handle public keys that are not authorized by a valid certificate from the company. My recommendation is to reject all keys that fail to adhere to the company policy. This is set under the policy icon; "Policy Failures" tick the "error" selection. The other choice, to store all undefined keys in a pending area just creates extra administrative work. Someone has to be assigned to regularly check the pending area, and delete keys that has been rejected, and just consumes disk space. (Note; The possibility to list keys in the pending area is only existing in PGP's administration version. Possibly to reduce a confusing choice for the end users that are not expected to use this facility.)
The certificate server will thus reject keys that violate this policy. To implement this rule, go to the Policy-icon with the webbrowser. Go to "UserIDs Must be signed by" and click on "new". Another screen says "All keys submitted to the server must be signed by Key ID:" Here we shall add the last (least significant) 16 hexdigits that appear in the fingerprint that belongs to the corporate signature key.
Note 1. It is not a requirement that submitted keys must be directly signed by the specified KeyID. It is enough if the submitted keys are indirectly certified by a meta introducer. This makes it much easier to administrate in a large organization.
Note 2. The certificate for submitted keys must be in exportable form. Otherwise they will be rejected.
To find what the KeyID is, start pgpkeys, mark the signature key, and right click so we can check the keys properties. Right click in the fingerprint field, and copy the whole fingerprint. Paste it into the web readers input field. Remove all hex digits to the left, (the most significant digits) until there is only 16 hexdigits that remains. Remove all spaces between the hexdigits. Place the character "0x" to the left of the 16 hexdigits. Like this: 0x0B635BA53CEAEF2C
Click on "Submit"
Go to the field "Policy failures", and click on "Error". This means that the certificate server will reject every key that violates the policy, by not being signed by the corporate signature key. Finally, click on "Update server"
Note. Incorrect warning message.
When the certificate server (ver 1.02) is configured to consider unauthorized keys as an error and reject them
And
A PGP client tries to upload an unauthorized key that is not signed by the defined keyID
Then
The PGP Client program gives this warning message:
"The key you are trying to add to the server has failed the server policy check. The key will be stored in a pending area for review by the server Administrator"
The correct warning message should rather be to inform the uploader that the key has been rejected. Warnings that are misleading can fool the operator to search for a problem that does not exists.
---
Deleting keys.
Normally, one does not want to delete keys. They should instead be revoked. But during a pilot phase, we want to be able to delete testkeys that has been created and uploaded. Just for cleaning up purposes. A typical policy is to only allow the administrator to delete keys. The administrator is defined in the configuration by his keyID.
Defining which key that is allowed to delete other keys.
Go to the Configuration, and the field "Allow access by", mark the wildcard star ("*") that we added earlier, and click on "edit". A new screen appears, and in the field "Access Permitted" click on "delete". Click on submit. A new screen appears, click on Update server.
This rule means that we in this moment are giving everybody the right to delete keys. That is of course not what we want, so in the next step we will restrict the right to delete keys.
Go to the icon "Configuration". Go down to the field "Allow access by:" and click on "new". Paste the key ID into the field "Allow access by", and below the line "This entity is" click on "KeyID" and one line below, click on Delete. Finally click on submit, and update server.
These lines has now been added near the bottom of the configuration file;
allow ip * add
allow keyid 0x3Ceaef2c delete
(the key ID above belongs to Laszlo, just as an example. It should be replaced by the administrators key ID.)
A bug in the configuration program for ver 1.0.2 (fixed in 2.0), forces us to manually edit the configuration file. With the Notepad editor, open the file;
C:\Program Files\Network Associates\PGPCertd\etc\pgpcertd.cfg. At the buttom, there is a line which says: "allow ip * add". This must be manually changed to; "allow ip * delete". Save the file. The bug consists of having a configuration program that does not create the configuration we have asked for.
Thus the correct lines in the configuration file should be;
allow ip * delete
allow keyid 0x3Ceaef2c delete
Make a backup copy of this file, because the configuration program will change our manually fix back to "add". Thus this manual editing must be done as the last step every time we in the future use the configuration program.
How to actually delete a key.
Note the difference between deleting a key on the server, and deleting it from your local keyring. To delete a key on the server, you must first search for the key from the PGP client program:
PGPKeys -> Server->Search -> enter a search criteria that will make the keyserver to response, and list the/those keys you want to delete from the server. Mark the key you want to delete from the list, right click, on the mouse, and select "Delete from server"
How the certificate server keep tracks of whether it is a valid key that has sent in a request for deleting keys, or signed keys.
can PGPThe use of KeyID;
1) a signed public key is sent to the server.
2) The server do already contain the public key that belongs to the authorised signer. If the signature is verified correct, then, the certificate server, compares the KeyID in the specified Mustsig- field, and
Once you have got so far, we can now increase the security. In the certificate server there are two fields that can be configured to use a KeyID in order to perform an operation;
There is a small, but existing possibility that another public key has the same key id as the administrator. (or it could be deliberately created to have the same keyID.) Thus we simply reduce this possibility by adding yet another 16 hexdigits to the key ID. The administrators fingerprint, consists of a total of 40 hexdigits. Note that the last 8 hexdigits (32 bits) in the fingerprint is the same as your key ID. Take yet 8 digits from the left, to double the length of your keyID.
0xB6F5 DE0A 39EA 41B7 8744 6C7A 0B63 5BA5 3CEA EF2C (this is Laszlo's complete fingerprint, 40 hexdigits, 160 bits)
0x0B635BA5 3CEAEF2C (This is Laszlo's longer keyID. 16 hexdigits = 64 bit, for increased security)
0x3CEAEF2C ((This is Laszlo's normal keyID. 8 hexdigits = 32 bit, for normal or low security)
With this increased security, the two added lines in the configuration file will become;
allow ip * delete
allow keyid 0x0B635BA5 3CEAEF2C delete
----
Removing private keys from certificate server.
There is no need to keep the private part of the administrative keys on the certificate server, so let us move them to a safer place. The private key for the three recovery keys can be locked into a safe. The private part of the signature and revocation key can be moved to a PC, and all administrative tasks like signing/revoking/adding/deleting keys can be performed from this PC.
How to do this.
Export the administrative key, including their private parts, to two floppies. One of them can be locked into a safe. The other floppy can be imported to PGP on a PC that is used for remote control of the certificate server. When everything works as expected, wipe out the private keys from the certificate server. If it is desirable to not let one person alone perform all administrative tasks, assign the revocation key to one trusted employee, and the signature key to another employee. Thus all power is not in the hands of a single individual.
Estimating required size of database.
To use a large amount of keys, like those on the public key servers on Internet, which totals to about 28 Mb, you might have to increase the computers paging file size. Control panel-> System->Performance->virtual memory->paging file size. My computer with 64 Mb RAM, is set to initial size=200 MB and Maximum size =400 Mb. But don’t worry, the computer will complain if it reaches the roof.
All keys are stored in C:\program Files\Network Associates\PGPcertd\data\id2entry.dbb
The exact size of required diskspace depends on the keysize of the keys, the amount of certificates attached, if photo's are included, length of usernames etc. 60 keys = 632 kb
---
Things I have not managed to function.
---
Default access - locked to read.
In the configuration tool we can decide what access a default user, shall be allowed to have. It is;
None (probably used for closed groups), Read, Add, Delete. A closed group might want to choose None, as the default access, just to avoid unnecessary revealing of their internal work. Such as how many, and who in their staff is using PGP. The problem is that the setting of None, add or Delete are all treated as Read access.
The documentation, and comments in the configuration file; PGPcertd.cfg defines two more access method; compare and search. Even by manually editing the file, these two choices are still locked to read access.
---
No Replication.
I have not succeeded to make it work. Nothing happens. The logs do not show anything, so it seems that no activity at all is taking place.
But here is how far I got.
* Create an empty file, and add its location to the configuration program.
If you do not create an empty file, The error message from the configuration program will be:
C:\pgpcertd.150: To perform replication, both RepLogFile and Replica must be specified. Errors processing configuration file. Server not started."
The replication engine's eventlog also complains that there are no replica instruction in …\etc\pgpcertd.cfg. But if one look at that file, there are clearly two lines in there:
replogfile "filename"
replica <domainname.of.the.host>
Once you have tried to use the replication, the configuration file is considered as not correct. To continue with further configuration, you must restart the computer, and go to the certification servers homepage, (http://certserver.qainfo.se/certserver/default.htm )and from there browse to the configuration menu. That was quite tricky to find out. It does not help to manually edit …\etc\pgpcertd.cfg, and remove the two lines that contain the keywords replogfile and replica.
Then two odd things happens.
1) The browser time's out because it can no longer find the configuration program cs.exe. Solution: Restart the computer
2) If you try to read the license agreement, on the homepage, the response is:
"HTTP/1.0 403 Access Forbidden (Read Access Denied - This Virtual Directory does not allow objects to be read.)"
Solution: The read access for the directory /certserver/doc is lost, and must be set again by
Start->Programs->Microsoft Internet Server_>Internet server manager->click on properties on the webserver -> directories ->/certserver/doc -> edit properties -> and set access to read.
---
To contact the author:
--- end ---
--- the rest is just a scratchpad, for coming work notes about ver 2.0 ---
To add.
Add how to install encrypted communication between clients and the server to avoid interception of split keys.
How to start the certification server after power failure.
How to use the replication engine.
How to only allow signed commands to add and delete keys to the server.
How to create trusted introducers, one at each location.
etc.
If the power goes down, the certification server should go up and continue where it was, when the power comes back. Thus we must place two programs in NT's start menu. Create a shortcut from: Internet Service Manager at;
C:\Winsrv\system32\inetsrv\inetmgr.exe --> C:\Winnt\Profiles\Default User\Start Menu\Programs\Startup (=NT's start menu)
[add how/if the certificate server can automatically be started]
Set "secure port" to its default; 636, the well known port for LDAP over TLS (LDAPS)
Tick "Required" in "Secure mode"
In PGPcertd, uncklick "disable" in the field "secure port"
*) Write down the least significant 64 bits (= 16 hex character) in the signaturekeys fingerprint. If the complete fingerprint is; BDE2 198B C9B9 C938 11FC 889F 944E A57D 4E44 D675, then the wanted hex characters are; 944E A57D 4E44 D675
*) In the certificate servers configuration menu, go to the bottom, and delete the existing starsign, ("*"), and click on "New" to add a new rule in "Allow access By:" Enter the 16 hex digits by adding 0x, in the beginning, and remove spaces between the digits. Like this; 0x944EA57D4E44D675, and click on "KeyID" and "Access Permitted:" should be "delete", and finally click on submit.
Do it once again, but add yet another rule; Since signed request must come from somewhere, we must also define that it is allowed to originate from anywhere. Go to the menu, and click New" and add a star ("*") in the "Allow access by" field. And let the access become "delete"
Thus the order of rules is:
Let the signed request come from any IP-adress. (that is the star sign.)