(GSKit) Access to the key database is not allowed (ssl_error 6003)

[jjacobs207]

(GSKit) Access to the key database is not allowed (ssl_error 6003)

I've looked at other forum entries on this topic, and I have read the README accompanying HTTPAPI. However, I still have a specific issue I would like assistance with that's not making sense to me, unless there's more to it than the IFS folder/file permissions, such as *PGMR and Special Authorities.

Folder:
/ *PUBLIC *RX
QIBM *PUBLIC *RX
UserData *PUBLIC *RX
ICSS *PUBLIC *RX
Cert *PUBLIC *RX
Server *PUBLIC *EXCLUDE, QSYS *RWX, QLWISVR *RX, QTMHHTTP *RX

File:
DEFAULT.KDB *PUBLIC *EXCLUDE, QSYS *RW, QLWISVR *RX, QTMHHTTP *RX
DEFAULT.RDB *PUBLIC *EXCLUDE, QSYS *RW

This set up does not work for public (User Class *USER, Special Authorities *NONE). It gives the GSKit Access not allowed error as in Subject line.
However, this works fine for IT staff (User Class *PGMR, Special Authorities *ALLOBJ, *SERVICE). I assume it works because the IT staff has *ALLOBJ.

IT Management does not want to give *PUBLIC *RX to Server folder or *R to DEFAULT.* files.
Questions:

• Is this being overly secure?
• Is it required for *PUBLIC to have the authority regardless?
• If I use a program that executes HTTPAPI and I make its owner QPGMR, USRPRF *OWNER, USEADPAUT *YES and QPGMR has *ALLOBJ, will that solve the problem?
• If so, would this be a recommended solution or a horrible idea?
• If my solution is a horrible idea, what better solutions do you have?

Thanks!

[Scott Klement]

• Is this being overly secure?

That depends on what you're storing in the certificate store and why your company feels the need to keep it secured.

My experience is that people who take the attitude of keeping it secured usually can't answer that question. They just keep it secured because "IBM must have set it that way for a reason" and don't really understand what's going on, so they secure it needlessly.

But I have no way of knowing why you're doing it.

I have had people bring in a security expert such as Robert Andrews in the past and so far, at least, everyone ended up granting access to *public or at least to the users that need to run it. But again, I don't know what you're storing in it or why. Maybe you're a military organization that uses that keystore file to store top secret crypto keys... in that case, it should definitely be kept restricted.

This is not a decision someone else can make for you. Your company needs to understand the risks and make its own decision.

• Is it required for *PUBLIC to have the authority regardless?

Not at all. It's a requirement for the users who need to run programs that perform SSL encryption to have access. It provides access to the necessary cryptographic keys to do the encryption.

Also note that this has absolutely NOTHING to do with HTTPAPI, aside from th fact that HTTPAPI uses the crypto routines that come with the operating system. This is 100% an IBM i operating system question.

That's why users like QSYS, QLWISVR and QTMHHTTP have access, so that the server applications that IBM provides can do SSL.

• If I use a program that executes HTTPAPI and I make its owner QPGMR, USRPRF *OWNER, USEADPAUT *YES and QPGMR has *ALLOBJ, will that solve the problem?
• If so, would this be a recommended solution or a horrible idea?
• If my solution is a horrible idea, what better solutions do you have?

That wouldn't work because usrprf *owner and adopted authority have no impact on IFS objects.

You would have to use profile swapping if you wanted to bypass the need to grant users access to the SSL crypto key stores. That would work, but imho, it's 100x less secure than just giving the users access.

Granting the users access to this file means that they can utilize any SSL certificates (and related crypto keys) you've stored in there. That means one of your users could potentially steal your SSL certificates and use them on another machine. If you use the crypto keys for something besides SSL (such as validating that an application is genuine) they could also use them for that. That is the risk at hand. (Note that most other OSes give users access to the certificates by default.)

By contrast, using profile swapping (or adopted authority if it would work, which it wont) could potentially allow them to find a way to insert their own commands being run under the elevated authority. This would essentially allow them to do ANYTHING on the system, which I personally would say is much more dangerous than just giving them access to your SSL certificates.

[jjacobs207]

Scott, thank you once again, and I understood what you said. We are not holding the access to nuclear missile silos!

Here's the specific situation, and perhaps based on that you can give me your opinion on best solution:
(My take on what little I know and am learning about the certificate store is that access to it is all or nothing, meaning you cannot limit an authorized user to a specific portion or key in the store.)

Using HTTPAPI and SSL, we're beginning to reach out from the iSeries to gain access to cloud solutions, such as Oracle's suite of retail software and Vertex Tax and who knows what else in the future. Let's just discuss Vertex Tax here as the example. Around forty canned software programs call a single canned software program to calculate and return sales tax. Vertex Tax used to be on-premise on the iSeries, along with the other canned software to which I just referred. The single canned software program called the tax calculation software. Now, Vertex Tax is moving to the cloud. Therefore, I've changed the single canned software program to call my custom program which executes HTTPAPI to call an in-house non-iSeries Web API that then calls the Vertex Tax API.

So far, it's been me testing the new solution and IT QA staff, where all of us have *ALLOBJ authority. I'm presuming this is how we're able to run the solution without getting the "GSKit Access is not allowed" error. Now, however, we're in UAT and ordinary users are testing the solution. They obviously do not have *ALLOBJ authority. When they run the solution, the "GSKit Access is not allowed" error is occurring and the intended API is not being called. Yikes!

Based on your first response to my post, I'm gathering that the most obvious choices to solve this issue are the following:

1. Give *PUBLIC read-only access to the certificate store, as almost any user might need to run a program that accesses Vertex Tax, Oracle's Retail Suite, or future cloud solutions the organization chooses to implement.
2. Use user profile swapping, where the program that calls the API swaps to an authorized user of the certificate store before executing HTTPAPI and then swaps back (restores the current user) to the calling user.
3. A more elaborate solution, involving separating the user/program requesting the information from the solution that actually makes the request for the information (i.e., API call). This could use MQ, data queues, database files, or IFS files. Essentially, this would consist of three elements: program requesting the information, NEPs/batch jobs/service jobs running under a user that has access to the certificate store and makes the API call, and intermediate storage for communication between the two parties.
4. Something I have not thought of.

Given this additional information, I would appreciate your comments, pros/cons to the different solutions, and/or other options that I have not thought of.

[Scott Klement]

Here's the specific situation, and perhaps based on that you can give me your opinion on best solution:
(My take on what little I know and am learning about the certificate store is that access to it is all or nothing, meaning you cannot limit an authorized user to a specific portion or key in the store.)

True, but you can create your own certificate store that have only the certificate(s) you want them to have access to, and only grant them access to that certificate store.

Bear in mind that these files are also used to validate the certificates received from others. So if Oracle or Vertex Tax sends you a certificate, it will check it against this file to be sure it is valid. So if you want to restrict to only particular certificates, you need to be careful that you get everything needed. (i.e. the CA certificate chain used to validate other's certs) And if they change them, you'll need to be ready to change your custom certificate store.

Personally that sounds like overkill to me... but it's an option.

Based on your first response to my post, I'm gathering that the most obvious choices to solve this issue are the following:

1. Give *PUBLIC read-only access to the certificate store, as almost any user might need to run a program that accesses Vertex Tax, Oracle's Retail Suite, or future cloud solutions the organization chooses to implement.
2. Use user profile swapping, where the program that calls the API swaps to an authorized user of the certificate store before executing HTTPAPI and then swaps back (restores the current user) to the calling user.

I feel like I've already given you the pros and cons to these options.

1. A more elaborate solution, involving separating the user/program requesting the information from the solution that actually makes the request for the information (i.e., API call). This could use MQ, data queues, database files, or IFS files. Essentially, this would consist of three elements: program requesting the information, NEPs/batch jobs/service jobs running under a user that has access to the certificate store and makes the API call, and intermediate storage for communication between the two parties.

That would work, but of course you'll need to carefully plan how to secure the access to the intermediate storage. Seems like a lot of headache to me -- I would only do this if there's a very good reason to keep the certificate store secure.

Also bear in mind that with a solution like this, you have to restrict user's object-based authority to the data queues, database files, IFS, etc. Otherwise everyone can run it, and you're back to the same concerns of giving *PUBLIC access. So it seems this doesn't really buy you anything vs. just giving authority to the individual users.

1. Something I have not thought of.

Can't give you pros/cons of that without knowing what it is, lol.

Personally, I'd start by looking at what is stored in your *SYSTEM certificate store. See what you're risking people having access to.

If it's just the CA certs needed to validate the sites you're connecting to, they're probably all in the public domain anyway... so why fuss so much over this?