Top Secret

This isn't exactly a TSS question; it's digital certificates again—I'm still figuring them out.  Actually I think I already know that a server can have more than one certificate; what I'm trying to understand is how they work together.  If you want to steer me to a better forum for this question, I won't mind.

We're signing on to the system using a telnet emulator Reflections v11, and we're in the process of upgrading to Reflections v16.  The current certificate is sha1, and the new version of Reflections will use sha256.  So for a while, both versions need to be able to talk to the LPAR, and that means more than one certificate must be in place.

So when a client and server attempt a handshake, how is it determined which certificate is to be used?  Last week I tried just adding a sha256 certificate to the server keyring and marking it DEFAULT, and at some point after that we were unable to connect using the old Reflections.  We haven't established yet whether it was because I "successfully" added the sha256 cert, but I'd like to know more before I embark on that road again.

Bob,

The functionality you are looking for needs to be supported the application. Generally speaking, most SSL application do. This allows an application to have different sites/users connect to it with different certificates.

Imagine if it didnt, there would be no accountability and tracking since everyone used the same certificate. If someone stole the certificates, you would have to re-issues new certs for all your users. If you used multiple certs, you would only need to re-issue new certs for those users/sites, that used the stolen certs.

The server sides keyring needs to contain the multiple sets of certificates used by the various sites/users. 

When  the client tries to connect to server for client authentication, it present it's certificates for validation. The server's keyring will be searched for the matching certificates. If found, the connection will be successful. If not found, the connection will fail.

Joe

Hi, Joe.  You're talking about client authentication, right?  When that's in effect, I guess you're saying the client sends its certificate and the server looks through the server's list of client certificates to find a match.  But my question is about the other direction:  For server authentication, when multiple clients are expecting different server certificates, how does the server select which certificate to send to the client?

I take it each client knows what certificate it's expecting.  Is it part of the handshake that the client will tell the server something that identifies the expected server certificate?

I think what you are missing here in the z/OS world is that the network folks should be using Policy Agent (PAGENT) to manage ports, IDs and certificates for Telnet. When you are trying to support multiple certs for TELENT (SHA1 and SHA2) PAGENT could be configured to have the SHA1 cert using one port and the SHA2 cert could be on another port. This will mean your users configuration of Reflection will need to be tweaked accordingly to point at the correct port. With PAGENT involved you can have the SHA2 cert as the default cert in the key ring and the SHA1 one there as just being another personal cert on the key ring. When we migrated TELNET to SHA2 we were doing all of the changes in conjunction with our network group. My 2 cents for a Friday afternoon!

This was a while ago, but PAGENT is exactly what someone at our installation (not I) figured out.  We had to jump through a few additional hoops, and I contributed in a very modest fashion, but most of this happened through knowledgeable folks on the systems side.  It looks like we're up and running with the new sha256 certificate now, and good for another few years.

By the time this certificate is ready to expire, no doubt the new one will have to use a new encryption scheme that no one now has ever heard or thought of.