[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Application is not registered with DCM!



Good morning Scott!

Just wanted to write a preliminary 998 (EDI-ack) email, to thank you
profusely. Your email is TS 11.15pm PST on a Sunday night, so it was likely
1.15am on Monday where I think you are. You are amazing.

I signed onto the DCM, but (as expected) cannot see the *SYSTEM cert store,
so am applying for *SECADM. Lord knows what the password was. Maybe it was
never created.

Will report back if I have any more difficulties - meanwhile, is it worth
your time to point out to the community what extra advantages it brings to
create an actual Application ID within the DCM, and then pass said AppId to
HTTPAPI (ie. as opposed to omitting the call to https_init(), or passing
*Blanks?

Thanks again,
Peter

-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Sunday, January 14, 2007 11:15 PM
To: HTTPAPI and FTPAPI Projects
Subject: Re: Application is not registered with DCM!

Hi Peter,

> Forced to run a working HTTPAPI app (1.11) from a backup AS/400, we 
> got the error in the title. Alas, all I can remember about registering 
> my app with the DCM, almost 2 years ago, was that I had to use OpsNav 
> (not my forte), and that it was a royal pain in certain parts of the body.

No, that's incorrect.  You don't use OpsNav.  You use the admin instance of
the HTTP server.  You connect with your web browser.

Since you say you've done this already, I'll assume that you already have
all of the prerequisite software installed.  Let me know if that's not the
case.

HOW TO CHECK IF THE ADMIN SERVER IS RUNNING:
a) Type WRKACTJOB SBS(QHTTPSVR)
b) If it's running, there'll be at least one job named "ADMIN".

HOW TO START IT IF IT'S NOT RUNNING:
a) Type STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)

HOW TO CONNECT TO THE DIGITAL CERTIFICATE MANANGER AND LOG INTO THE *SYSTEM
CERTIFICATE STORE:
a) Open a browser on your PC
b) Connect to your System i at port 2001.  For example:
     http://as400.example.com:2001
c) Sign in with an account that has adequate authority.
d) Click "Digital Certificate Manager"
e) At the top/left click "Select a Certificate Store"  (If this is a fresh
install of the DCM, you'll have to create the certificate store first.  If
that's the case, see the README member in HTTPAPI.)
f) Choose "*SYSTEM" and click "continue"
g) enter the password you assigned to *SYSTEM when you created it, and click
"continue".

HOW TO CREATE AN APPLICATION PROFILE:
a) Click "manage applications" on the left (this option doesn't exist until
you've logged into the *SYSTEM certificate store.)
b) Select "Add Application" and click "Continue"
c) Select "Client" and click "continue".
d) The last screen is different for each application. Make sure you make a
note of what you put in the "Application ID" box at the top, however, since
this is what you'll need to pass to https_init().


> I did seem to remember that Scott had said something about NOT having 
> to register, with recent versions of his life-saving software, so I 
> loaded 1.17 onto the backup machine. Then I altered the call to 
> https_init() to pass *Blanks.

Correct.  You don't even need to pass *blanks to https_init().  Just omit
the call to https_init() altogether.  This is what I use in my applications
(unless I need client certificate support)


> However, the error was the same (I followed through to the code in 
> COMMSSLR4 shown after my signature). And, actually, all it says in 
> Scott's CHANGELOG
> is:
> - Allow *BLANKS for the Application ID in https_init(). When *BLANKS 
> is passed, it will use the default settings in the *SYSTEM certificate
store.

Yes, it also says this:

  - If an https:// URL is requested, but https_init() has not
       been called, call https_init(*Blanks) automagically.


> Can anyone please either point me to CLEAR instructions on how to get 
> into OpsNav and do whatever set-up is necessary with the DCM

The notes in CHANGELOG weren't intended to be "instructions", they were just
intended as an aid so I could keep track of what I changed in each release.
I get a lot of questions from people who are using an old release -- it's
helpful to be able to check and see whether I already fixed the problem
they're complaining about :)

Here are some clarifications that might help:

   a) You DO need to install the DCM and create the *SYSTEM
      certificate store.

   b) You DO NOT need to create an application-id, but you can if
      you want the added capabilities it offers.

      If you do not create an application id, you have to TELL HTTPAPI
      about that by omitting the call to https_init(), or passing
      *BLANKS instead of an application-id.

   c) The README member included with HTTPAPI contains the minimal
      steps needed to get SSL working.  If you WANT to use the
      extra capabilities of an application ID, I've provided the
      additional steps for that at the top of this e-mail.


> (eg. altering the default settings), or else tell me how I can adapt 
> my code so as to make the https_init() call, yet avoid having to 
> register with the DCM? (I did a Google on registering with the DCM, 
> did not find anything I personally could follow).

You don't have to alter the default settings unless you want to.  The
default settings work just fine.

> c                   eval      rc = gsk_environment_init(wkEnvh)
> c                   if        rc <> GSK_OK
> c                   if        rc = GSK_AS400_ERROR_NOT_REGISTERED
> c                   callp     SetError(HTTP_NOTREG: 'Application '
> c                             'is not registered with DCM!')

That's nice,but it's not the part that assigns the application ID, it's only
the part where things fall apart if you haven't assigned one!

The part the handles *BLANKS vs. an application ID looks like this:

C* If no application ID was given, use the *SYSTEM certificate
C* store as our keyring:
c                   if        peAppId = *blanks
c                   eval      rc = gsk_attribute_set_buffer(
c                              wkEnvh: GSK_KEYRING_FILE:
c                              '*SYSTEM': 0)
c                   if        rc <> GSK_OK
c                   callp     SetError(HTTP_GSKKEYF:'Attempt to use ' +
c                               '*SYSTEM cert store: ' +
c                               ssl_error(rc))
c                   return    -1
c                   endif
c                   endif

C* If an application ID was given, use that to associate with the
C* digital certificate manager:
c                   if        peAppID <> *blanks
c                   eval      rc = gsk_attribute_set_buffer(
c                              wkEnvh: GSK_OS400_APPLICATION_ID:
c                              %trimr(peAppID): 0)
c                   if        rc <> GSK_OK
c                   callp     SetError(HTTP_GSKAPPID:'Setting ID: ' +
c                               ssl_error(rc))
c                   return    -1
c                   endif
c                   endif

Make sure that if you've tried to pass blanks, the GSK_KEYRING_FILE code is
called.  I'm not really sure what else to tell you, except that it works on
my system!  Maybe a certain release or PTF level is required?  I don't know.

-----------------------------------------------------------------------
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
-----------------------------------------------------------------------