[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
-----------------------------------------------------------------------