Re: Just got a "(GSKit) Access to the key database is not allowed." exception.

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Hi James,

Adopted authority (aka USRPRF(*OWNER)) does not work with IFS objects. 
It never has. This is not specific to HTTPAPI, it's a facet of the 
operating system.

If the iNav approach doesn't work for you, try setting the authorities 
to those objects...   Here's a an excerpt (copy/paste) from the README 
member:

---begin excerpt---

GRANTING ORDINARY USERS PERMISSION TO RUN SSL APPLICATIONS
WHEN THE PRECEDING SECTION DIDN'T WORK
---------------------------------------------------------------------
Some have reported that the preceding instructions don't work,
because the user doesn't have access to the underlying files
in the IFS.  To solve that problem, grant authority as follows...
In this example, I'm giving a user named SCOTTK access to the
files.  (Change SCOTTK to the proper userid when you do it)

  CHGAUT OBJ('/') +
         USER(SCOTTK) DTAAUT(*RX)
  CHGAUT OBJ('/QIBM') +
         USER(SCOTTK) DTAAUT(*RX)
  CHGAUT OBJ('/QIBM/UserData') +
         USER(SCOTTK) DTAAUT(*RX)
  CHGAUT OBJ('/QIBM/UserData/ICSS') +
         USER(SCOTTK) DTAAUT(*RX)
  CHGAUT OBJ('/QIBM/UserData/ICSS/CERT') +
         USER(SCOTTK) DTAAUT(*RX)
  CHGAUT OBJ('/QIBM/UserData/ICSS/CERT/SERVER')
         USER(SCOTTK) DTAAUT(*RX)
  CHGAUT OBJ('/QIBM/UserData/ICSS/CERT/SERVER/DEFAULT.KDB')
         USER(SCOTTK) DTAAUT(*R)
  CHGAUT OBJ('/QIBM/UserData/ICSS/CERT/SERVER/DEFAULT.RDB')
         USER(SCOTTK) DTAAUT(*R)

If you wish to give all users access to run SSL programs, then
you should change USER(SCOTTK) to USER(*PUBLIC).  You can also
use an AUTL if you like by specifying AUTL(your-autl) instead
of USER(your-user)

NOTE: Adopted authority does not work in the IFS.  Please
       grant permissions by the actual userid, not the adopted
       one.

---end excerpt---




On 1/17/2012 5:27 PM, James Lampert wrote:
> Scott Klement wrote:
>
>> The OS routines, by default, store crypto keys in the
>> /QIBM/UserData/ICSS/CERT/SERVER directory of the IFS.  The names of the
>> objects in that directory are DEFAULT.KDB and DEFAULT.RDB.
>>
>> If the user doesn't have authority to read those files, then they can't
>> load keys and therefore can't do any SSL.
>
> Uh, regarding the instructions in the readme member, they're specific to
> Ops Nav, and when I bring up "System i Navigator," I don't see anything
> but "Basic Operations" in the connection. (We're not an Ops Nav shop.)
>
> And while I do see "Users and Groups" in the Admin web page, I don't see
> anything for granting users authority to the *SYSTEM certificate store.
>
> What I *did* find was that (1) giving *OWNER authority to your HTTPAPI
> *SRVPGM, and/or my WTGOOGLEC *SRVPGM didn't seem to make any difference,
> and (2) giving *PUBLIC *RX authority to the above-named directory and
> the above-named files (from WRKLNK) *did* seem to do the job.
>
> --
> JHHL
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list.  To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
>

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------