I suppose it depends on who has access to it. That should be the 1st constraint. If it is something like CICS.. it may be a bit weirder. You can startup the gsksrvr trace which will trap any usage for the keys. As for whether they are in use.. it is somewhat "in the eye of the beholder". A client or server can always choose to trust something even if it is expired.. or doesn't match etc.
It also depends on what controls and where the certs and keys exist. If they are in RACF .. I think there are some newer controls to see when a cert is used. The RACF-L should have the details. Rob Schramm On Wed, Jan 16, 2019 at 3:21 PM Seymour J Metz <sme...@gmu.edu> wrote: > This list has more readers and RACF-L has more concentrated expertise. If > it were me, I'd post the question in both. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf > of Bob Bridges <robhbrid...@gmail.com> > Sent: Wednesday, January 16, 2019 1:09 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Digital certificates, probably inactive > > Folks, I'm new here. (I usually hang out at TSO-REXX and RACF-L.) In > fact I joined IBM-MAIN specifically so I could ask some newbie-type > questions about SMP/E. But just now another more urgent issue has come > up: Is this a good place to ask a few general questions about digital > certificates? > > I'm handling security for a client whose previous security jock apparently > had better things to do, so I find there are a lot of cleanup issues to > deal with. One has to do with digital certificates, which should be in my > bailiwick but I'm new at them. I see several IDs with one keyring each: > > 1) In most IDs the keyring is empty. I presume I can delete those empty > keyrings without any risk. > But since I'm here asking questions I may as well check to be sure: > Nothing bad can happen if > I remove an empty keyring, right? > > 2) In one ID (let's call it USER3) the keyring has 3 certificates: > a) The HANDSHAKE certificate (call it CERTA) expired in 2011. > b) CERTA is signed by CERTB, which expired in 2014. > c) CERTB is signed by CERTC, which expires in a few months. > > I brought this to the attention of my boss, but no one knows what this > collection of certificates > may ever have been used for, if indeed it was ever used at all. > i) Since the certificate chain is so long expired, is it even possible > it's still be in use? > ii) If we choose to disconnect it just to see whether anything breaks, > what method would you > recommend using? Something that could be reversed easily if > necessary, of course. Would I > merely remove one of the certificates from the keyring, being > confident that I can add it back > again afterward if desired? > > 3) Another ID (USER2) has 2 certificates in much the same state as USER3: > The HANDSHAKE cert is > expired, the signing (root) certificate is still good to go. So same > questions about this one. > > 4) USER2 also has, in the same keyring, a dozen or so apparently unrelated > certificates from the > CERTAUTH ID, all with usage CERTSIGN. I suppose they're useless and > can be removed? > > If this is not the right place to ask, feel free to steer me somewhere > else, with or without derisive flames as it suits you :). I'm reading > documentation, but it's also nice to get confirmation from experienced > admins, especially in a subject with so many corners and pitfalls. > > --- > Bob Bridges, cell 336 382-7313 <(336)%20382-7313> > robhbrid...@gmail.com > rbrid...@infosecinc.com > > /* Of a proposed course of action the Enemy wants men, so far as I can > see, to ask very simple questions: Is it righteous? Is it prudent? Is it > possible? Now, if we can keep men asking "Is it in accordance with the > general movement of our time? Is it progressive or reactionary? Is this > the way that History is going?", they will neglect the relevant questions. > -advice to a tempter, from The Screwtape Letters by C S Lewis */ > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Rob Schramm ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
