"please assign a private key..."

Joe,

to sign messages and decrypt data a private key is required for every local station. For more information about the PKI please have a look at

http://en.wikipedia.org/wiki/Public_key_infrastructure
http://en.wikipedia.org/wiki/Public_key

Regards
Heller

Joe,

these instructions are community driven, we have not verified them. They describe how to work with portecle which is a 3rd party software to work with keystores. Please have a look at the link section for a download link.

Regards
Heller

Joe,

I thought maybe a plain-English description of how PKI works and how it relates to Mendelson might help you.

The basic premise behind PKI is that *you* generate two keys (just a couple of big numbers; 1024 bits, 2048 bits, etc.) that are mathematically related (like ripping a piece of paper in half; the tear is unique). That's the "Generate Key Pair" option in Portecle.

Now, one of those keys you can give to the whole world. There's nothing private about it, hence it's called the "public key". The other one is super-secret . . . the "private key". If the private key is compromised, all hope is lost, so the file is usually protected on the filesystem and encrypted (3DES, I believe), so it requires a password, which you'll notice Portecle prompting for sometimes. Remember, the private key never leaves your control.

And here's why this arrangement is so special:

If someone uses your public key (which they can be freely given) to encrypt something, it can only be decrypted with your private key (remember that unique mathematical relationship?). This is confidentiality.

If you use your private key on something to "sign" it, anyone with your public key can be sure it came from you (because only you have the private key). This is authentication.

If you use your private key to sign the "hash" of something, anyone with your public key can prove that the message hasn't been tampered with. (A hash is another mathematical trick that derives a unique number from a piece of data; [almost] no two pieces of data will produce the same hash and the hash can't be reversed to determine the data.) This is integrity.

If you have both authentication and integrity, you also have non-repudiation. It's legally-admissible proof (at least in the US) that you sent exactly that message.

That's all good stuff. But how does the world know that the private key that was used to sign that message actually belongs to you? That's where Certificate Authorities (CAs) come in. If a CA signs your public key with their private key and adds some information (most importantly the "subject", the owner), it's now a "certificate" because it certifies that anyone with the matching private key is the subject named on the certificate.

Anyone can be a CA (all you need is your own key pair ; > ), but we pay big commercial CAs like Thawte and Verisign (same company, BTW) to purportedly verify that an authentic subject is going on the certificate. If someone other than a commercial CA signs your public key, it's usually called a self-signed certificate. There's nothing inherently less secure about a self-signed cert (AAMOF, there are ways in which it's more secure, but that's another discussion), however, most software that handles PKI has a built-in list of "trusted roots"...that is, CAs that are generally trusted...and if they are presented with a certificate signed by a CA that's not in the list of trust roots, they'll pop up a warning dialog. Some ridiculous software won't work with self-signed certs at all.

So what does this mean for Mendelson? Each pair of trading partners has to have a public/private key pair and has to exchange public keys. You use your partner's public key for encrypting messages you send to them and verifying the integrity of messages received from them. You use your private key for decrypting messages sent to you and establishing the integrity of messages you send to them.

Mendelson has two keystores (just files which can contain multiple keys), one at ./certificates.p12 and the other at ./jetty/etc/keystore. They're in different formats and they have to stay that way, which means you have to do double work with your keys. I start by opening Portecle, and opening the certificates.p12 store. Then you can select "Generate Key Pair". You'll want RSA keys (just one way of doing the math) and I recommend using a 2048-bit key size (1024-bit keys are near-crackable now, so during a multi-year lifespan, they're likely to be crackable). Leave the "Signature Algorithm" at "SHA1withRSA". The validity period is up to you, but if you're going to have it signed by a commercial CA, you pay by the year. And again, if you're signing yourself, the rest of the info is arbitrary, but a commercial CA will want accurate info. Here's what I'd have:

CN=myserver.mydomain.com
OU=My Department
O=My Company
L=My City
ST=two-letter abbreviation for my state (don't know how this is used outside the US)
C=US
E=some_role_account@mydomain.com

The "Key Pair Alias" is just the name by which it will appear in the list, for your reference.

I'm sure everything else was perfectly straightforward (; >) so here's where it gets complicated. You need your public key signed to get a certificate, which means that you have to generate a "certificate signing request" (CSR) file to give to the CA. In Portecle, just right-click the key pair you created and select "Generate Certification Request".

Now a CA has to act on that CSR. If you're getting a commercial cert, go to the CA's website and follow the bouncing ball. If your company has an internal CA that will be signing for you, you'll have to talk to your admin (for the MS CA, you'd start at http://someserver/certsrv). If you're going to sign it yourself, here's a good description of doing it with openssl: http://www.tc.umn.edu/~brams006/selfsign.html (it's really only the "openssl x509" line you need; the rest you're doing in Portecle).

What you'll get back from the CA is a "reply" file, which you have to match against the original key pair. In Portecle, you'll do that by right-clicking the key pair and selecting "Import CA Reply". What you'll end up with is a new entry in your keystore for the signed certificate. It's that certificate that you'll want to right-click and choose "Export" and give to your trading partner.

So now you've got one keystore ready to use with a public/private key pair and your certificate. Congratulations. All that's left to do is get the other keystore populated. There are a couple of approaches here, but what I do is export the keys and cert, then open up the other keystore and import them. Part of the reason is that I keep the keys and cert in a password locker for posterity, so I'm going to export them anyway. Here we go:

Right-click the key pair or cert and select Export.
For the cert, just accept the defaults and save the file somewhere.
For the key pair, select "Private Key and Certificates", give it a password (which you'll need to import it again), and then save the file somewhere.
Save and close this keystore and open the other one.
Select "Import Key Pair", browse for the key file, and follow the prompts.
Select "Import Trusted Certificate", browse for the cert, and follow the prompts.
Save and close this keystore.

Mendelson should now be good to go. Remember not to leave that exported private key lying around.

Thanks,
Chaz

If you need more help, let me know and we can take it offline if necessary.

Thanks,
Chaz