I think you mean QRETSVRSEC (not QRETSVRTSEC)
Cheers
Don
From: "Larry\"DrFranken\" Bolhuis" <midrange@xxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion"
<midrange-l@xxxxxxxxxxxxxxxxxx>
Date: 24/02/2021 11:12 PM
Subject: Unable to assign Digital Certificate to Web Server with
HTTP Server Administrator rc=ICS1003 *SOLVED*
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxxxxxxxx>
** This is for the Archives and has been solved **
Recently I was poked that
https://urldefense.proofpoint.com/v2/url?u=http-3A__Frankeni.com&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Kys-lxRCMpPr7up01Pp1FRjOe49ne6imWwi1b-ue8yQ&m=cqdneIruG-qC2BMjyQG8ujgyrFSKYPJOb-vpWHGIEe8&s=pgnjRhz8t60phXq_RtenC8Nv0PeE0ScePFHSzqPCnuo&e=
was not using SSL. In order to
fix that correctly I spun up a shiny new i 7.4 partition all current on
PTFs. I copied the web site over, and used DCM to request a certificate.
The returned certificate was loaded and I attempted to assign it to the
server using the CLI. It kinda almost ran but pages weren't right etc.
Very bizarre actually. WHen I removed the SSL from the site it worked
perfectly.
SO I used the HTTP Server Administration web server to attempt to assign
the certificate figuring that by editing the http.conf file I was
getting something wrong. That process acted like it was going to work
but after about 10 or so seconds it failed. At the bottom of the screen
it presented a link to the log. In there, this:
...] 000005b SystemOut O CA
number is: 3
...] 00000077 com.ibm.as400.httpsvr E Sign cert program failed
with rc=ICS1003
...] 00000077 com.ibm.as400.httpsvr E taskConfigureSSLForNormal
failed to sign certifacate splat.frankeni.com_2021 to application
QIBM_HTTP_SERVER_FRANKENI1
(Note ...] was the date and time)
After a time I opened a Case with IBM. The particular agent I was
working with was little help and had me do several things which were
pointless and actually cluttered up DCM badly as well as creating
additional unneeded web server instances. However in that process I
noticed at one point, and unfortunately I can't remember where, a note
about unable to access 'the stash.'
That was the memory trigger I needed. Immediately I viewed the lawyer
system value, QRETSVRTSEC and realized it was still 0. RATS. I set it to
1.
I then attempted to assign the cert in the HTTP Server administrator and
it failed again. OOPS! I logged into DCM, changed the *SYSTEM cert
store password, returned to the HTTP Server administrator and away we go.
You can now see that the page is up in ssl:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.frankeni.com_FrankenRules.html&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Kys-lxRCMpPr7up01Pp1FRjOe49ne6imWwi1b-ue8yQ&m=cqdneIruG-qC2BMjyQG8ujgyrFSKYPJOb-vpWHGIEe8&s=0faDcL9_ATW98gg8G_5qfr2DWtkFG56w3L9McAaYC_w&e=
As it works out the DCM password stash or some related bits to that were
NOT being stored due to QRETSVRSEC being set to 0. Once that was
corrected all is well. Note that normally this value will have been set
to 1 due to some other requirement but being a shiny new partition with
no other use than this I had not yet encountered a reason to set it to
'1'.
The reason for changing the password AFTER setting this system value was
to allow the stash to be updated and stored thus allowing the http admin
server to access and correctly assign the cert.
- DrF
midrange.com
