Re: Certificate labels
Love the gsktrace. Very educational. Rob On Tue, Aug 15, 2023, 14:14 Phil Smith III wrote: > Thanks to an off-list suggestion from Charles that I run a gsktrace, I've > now proven to my (and his) satisfaction that it does the label lookup and > then.never actually uses it after that. So at least I now understand the > results, even if they're arguably not quite what it should be doing. Or at > least the documentation could improve. > > > -- > 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
Re: Certificate labels
I believe that responding to a possible server request for a client certificate is the only purpose for the certificate label parameter *in a client configuration.* For a server, the label is a possible alternative to the usual convention of having the server present the default certificate on the ring. It could instead present the certificate indicated by a label parameter. I don't know that most servers support such an option. I am most familiar with the FTP server, and I believe that it does not. Charles On Tue, 15 Aug 2023 16:42:17 -0400, Phil Smith III wrote: >Peter Sylvester wrote: > >>it would be helpful, if you describe your scenario in more details: > > > >I'll short-circuit this: the STC is a client but is not using a client cert. >It's just doing a GET via HTTPS. > > > >My confusion was that: > >a. The doc doesn't really make it clear that a label is only meaningful >for a client cert. So in our reading, it was a way to force a specific cert in >the database to be selected-either for control (admittedly odd) or perhaps for >performance, as a quick way to get right to the right one. In my case, I was >using it as a debugging aid, to know which cert was the good one for the >connection. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Certificate labels
Peter Sylvester wrote: >it would be helpful, if you describe your scenario in more details: I'll short-circuit this: the STC is a client but is not using a client cert. It's just doing a GET via HTTPS. My confusion was that: a. The doc doesn't really make it clear that a label is only meaningful for a client cert. So in our reading, it was a way to force a specific cert in the database to be selected-either for control (admittedly odd) or perhaps for performance, as a quick way to get right to the right one. In my case, I was using it as a debugging aid, to know which cert was the good one for the connection. This is one reason I like gskkyman in general: it's easy to create a database containing exactly one cert, and if that works, you know it's the right cert. We have many customers who can't spell 'certificate' and so spend way too much time trying to answer that precise question. In this case, they were updating the server cert, needed a new root, and weren't sure they'd done it right. They are also using gskkyman in production, which is rare in my experience but certainly not "bad" per se. And since I started this effort, I've figured out that their biggest problem was not understanding that a gskkyman database can contain multiple certs! They were playing shell games, swapping databases between "new" and "old" and appropriate afraid that they'd get it wrong. Since they run for months without a restart, they had in fact gotten it wrong on one system, and had a nasty surprise when they did reIPL and things didn't come up. So, again, my goal was to make it easy to say "OK, if you explicitly tell it to use NEWCERT and it works, then you know that's the root in use, and you can remove the label and it will continue to work whether that system is hitting a server with the new cert or the old one. b. If you do specify a label for a root (non-client) certificate, it checks that the label exists but then ignores it. So if you specify an invalid label, it fails; but specifying ANY valid label will work as if you had not specified a label. I submit that this is a bug in theory, but it's also not clear how it should deal with that: if you specify a label, and then there's no client certificate involved, should it complain? That would be logical but a lot of work to implement. Hence my conclusion that some clarification of label use in the doc would suffice for this. I know most folks here don't care about this, and certainly not to this level of detail; my goal is twofold: to get this recorded to perhaps save someone else in the future; and to maybe get Wai or someone else at IBM to weigh in. I expect they're all enjoying NoLa, though! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Certificate labels
Hi, it would be helpful, if you describe your scenario in more details: Server has some certS, signed by some cas. (I skip possible intermediates). The CAs cert needs to be trustworthy buy the client. So far there is no client cert involved. If the server wants some client cert, it has to be configured to request it by sending a list of acceptable client CA names (or an empty list). Is this the case? If so, you should see this in a trace; if no, there is no client auth. solve previous step. If so, are the two client certificates signed by the same CA? If client auth is requested by the server, any of them can be sent. Does the server perform any kind of authorisation check on the identity of the client? Best Peter Sylvester On 15/08/2023 20:13, Phil Smith III wrote: Thanks to an off-list suggestion from Charles that I run a gsktrace, I've now proven to my (and his) satisfaction that it does the label lookup and then.never actually uses it after that. So at least I now understand the results, even if they're arguably not quite what it should be doing. Or at least the documentation could improve. -- 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
Re: Certificate labels
Thanks to an off-list suggestion from Charles that I run a gsktrace, I've now proven to my (and his) satisfaction that it does the label lookup and then.never actually uses it after that. So at least I now understand the results, even if they're arguably not quite what it should be doing. Or at least the documentation could improve. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Certificate labels
Way back 15+ years ago, when we were first porting our product to z/OS, we had to implement a transport provider, since there was no curl for z/OS at the time (or if there was, there was some reason we couldn't use it-I forget, but since several of our other platforms use it, I'm pretty sure we woulda if we coulda). So we did, using System SSL. Which has been very stable and reliable; our biggest issues, such as they are, have come from the fact that it's a lower-level API than libcurl. This means that when, say, TLSv1.2 or SNI come along, we have to make code changes, rather than just dropping in a new libcurl. But that's ok, we're used to it now. So this isn't a complaint about System SSL. Rather, it's a question that may simply come down to doc that's unclear (or at least was to us), and possibly a buglet. Our code is an application to the (x86-based) key and policy server, though it's an STC on z/OS, which reaches out to that server to get policy, stuff like that. All via SSL (and nowadays TLS). So what we need is the appropriate root certificate for the server's certificate. In Cryptographic Services System Secure Sockets Layer Programming (SC14-7495-40 - is that really a -40 version? Wow!!), it says: GSK_KEYRING_LABEL Specifies the label of the key that is used to authenticate the application. The default key is used if a key label is not specified. GSK_KEYRING_LABEL may be specified for an SSL environment or an SSL connection. If either the GSK_CLIENT_CERT_CALLBACK function or the GSK_SNI_CALLBACK function is registered, the key label can be set or reset by the callback function after a call to gsk_secure_socket_init(). When we read the doc above, we said, "OK, somebody MIGHT want to specify a label on their certificate when they're configuring. Not sure why, but we should support it". We thus allow for it on the TrustStore specification, and call gsk_attribute_set_buffer() if we find it. Recently, while helping a customer, we wanted to try to figure out which specific root certificate (of two) was being used with gskkyman. I thought "Well, we can just specify the label", so we did. And it worked: the connection worked first try! But I'm a paranoid sort, so I tried the other label. Which also worked. Hmm. So I tried a non-existent label, and it failed. In discussion offline with Charles, he noted that he's never seen a use for a label with a root certificate. Maybe the doc is just unclear, and "authenticate the application" would read better as "authenticate the client application", perhaps adding "when using a client certificate"? Maybe "The default key is used if a key label is not specified" implies client, and I do see that C-word in the fourth sentence, but conditionally-to me, at least, that doesn't scream "This is only relevant for client certificates". What say ye? I believe him about labels not making sense for roots, but does this seem unclear to others? The rest of the question is of course why it fails with an invalid label. I posit that specification of a label causes it to look for it, but then it doesn't get used later: So if the search fails, it complains, but if it succeeds, it ignores it. That would be a (trivial) bug, if so, I think. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
