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
