PKI_Tool

What is PKI_Tool and what does it do?

PKI_Tool is a GUI application for Windows that allows you to work with various PKI objects, including public and private keys, Users, Nodes, Certificate Signing Requests (CSRs), Certificates, and PKCS #12 containers (which can hold certs and/or private keys, encrypted with a pass phrase). It is an important part of the Sixscape Communications Domain Identity Registry server product. It is the primary administrator’s tool.

PKI_Tool can create a new user, including various information needed to create a client certificate for that user (their name, as well as their email address, their organization, their city, their state or province, and their country).

PKI_Tool can also create a new node (network device), including various information needed to create a server cert for that node (the fully qualified domain name of that node, as well as the organization that owns the node, and the city, state or province and country that the node is located in).

PKI_Tool can create Certificate Signing Requests (CSRs) for a user or a node. When it does this it creates a public/private keypair, then combines the public key with the above information for that user or node to create a PKCS #10 CSR. This CSR can be used to create a certificate. Usually a CSR is sent to a Certification Authority that generates an X.509 certificate from it, after verifying the accuracy of all of the submitted information. PKI_Tool can create a certificate from any CSR. CSRs can also be created by any IRP-enabled client application and uploaded into the PKI database via the IRP protocol, where PKI_Tool can access it.

PKI_Tool can create X.509 digital Certificates of various kinds.

It can create self-signed certs, or certs signed by higher-level (CA) certs. A self-signed cert is signed by the private key corresponding to the public key in the cert. Since there are no higher level certs that can be used to validate a self-signed cert, there must be some other way to determine if a self-signed cert is trusted. Typically a self-signed cert is made trusted by installing it in the “Trusted Root Authorities” folder of the local Certificate Store. In Internet Explorer, the Certificate Store can be found via Internet Options / Content / Certificates. Trusted root certs can be pre-installed by the browser vendor (e.g. Microsoft), added or replaced via Windows Update, or installed manually by the browser user. Root certs should only be installed in the “Trusted Root Authorities” folder if you are willing to accept any cert that is signed by that cert, or by any intermediate certs that chains up to thatroot cert (in other words, if you trust the entire certificate hierarchy below the new trusted root cert).

Most certs are signed by higher level certs (either the root cert or another intermediate cert). PKI_Tool makes it very easy to create certificates that are signed by the private key corresponding to any existing root or intermediate cert. End-entity certs cannot sign other certs. End-entity certs are the ones you actually use in applications, like an SSL server cert to enable SSL/TLS in a web server, or a client cert you use to enable S/MIME secure email or in Strong Client Authentication to a secure web server.

PKI_Tool can create a certificate hierarchy consisting of a self-signed root cert and an intermediate cert that was signed by the root private key. Initially there are no end-entity certs (e.g. server certs or client certs) in your new hierarchy, but you must have the basic hierarchy certs in order to create end-entity certs. Creating a certificate hierarchy is quite simple with PKI_Tool and only takes a few seconds.

PKI_Tool can also create PKCS #12 containers from a certificate and a private key. These can hold any number of certificates and/or any number of private keys. They normally contain one of each. They are encrypted with triple DES (3DES) symmetric cryptography, using a key derived from a pass-phrase. It is safe to store or transmit keying material in a PKCS #12 container, since only someone knowing the pass-phrase can extract the keying material from it. It is also possible for an IRP-enabled client to create a PKCS #12 container with their certificate and private key, and upload it to the DIR server using the IRP protocol. This provides key material backup and recovery. If they accidently delete their keying material (or their computer crashes) they can reload their keying material. They can also load their keying material on other computers just as easily. You download the PKCS #12 container from the DIR server, supply the passphrase, and the keying material is installed on your computer.

When someone uses (or is presented with) an end-entity cert, they must validate the cert by checking the digital signature on that cert using the public key from the intermediate cert used to sign it. They must make sure the cert is currently valid (the current date is between the “Valid From” and “Valid To” dates in the cert). They must also check the revocation status of the cert. Before they can trust the intermediate cert, they must validate it as well, using the public key from its parent cert, which is normally a trusted root cert. Basically there is a “trust chain” from any end-entity cert through some number of intermediate certs to a trusted root cert. To climb the trust chain, you must find each cert’s parent cert (the one it was signed with) and validate it as well. A parent cert’s Subject Distinguished Name is the same as the child cert’s Issuer Distinguished Name. This is repeated until you reach the root cert, whose Issuer DN and Subject DN are the same.

 

12