HTTPAPI & revoked SSL cert

[jtaylor___]

I have a job that uses HTTPAPI to make calls to an outside vendor. It makes a few hundred calls a day and has been in production for a couple of years. Twice in the past week, it's started throwing certificate errors and continued to do so until we ended the job and started a new one. As soon as we started a new job, the calls began working again. I wasn't in the office when the issues occurred, so I'm limited on what data I have. The IBMi job is a CGI job, but I'm not sure now if that has any bearing.


The joblog just lists:

[INDENT]From Library : LIBHTTP
From Program : HTTPAPIR4
From Line : *STMT[/INDENT]To Library : LIBHTTP
To Program : HTTPAPIR4
To Line : *STMT[INDENT]From user . . . . . . . . . : USER
From module . . . . . . . . : HTTPUTILR4
From procedure . . . . . . : UTIL_DIAG[/INDENT]Statement . . . . . . . . . : 4810
To module . . . . . . . . . : COMMSSLR4
To procedure . . . . . . . : SSL_ERROR
Statement . . . . . . . . . : 7142
Thread . . . . : 00000002

(GSKit) Certificate was rejected by the application
supplied exit program or certificate being validated by SSL processing was
revoked.
Cause . . . . . : No additional online help information is available.

IBMi 7.3, PTF's current as of 01 Sep 18.

Any thoughts?

(Cross-post from MIDRANGE-L)

[Scott Klement]

Is there an exit program set up that is rejecting the certificate?

[jtaylor___]

Is there an exit program set up that is rejecting the certificate?

Not that I know of. Would you happen to know what exit points to check?

[Scott Klement]

You can set an exit program in the Digital Certificate Manager under Application Definition.

Or, you can add one by calling http_xproc() in HTTPAPI with the HTTP_POINT_GSKIT_CERT_VAL point.

There may be other places, IBM is always enhancing this functionality, and I must admit, I haven't needed to look into these exit points recently.

[jtaylor___]

I don't see anything in DCM, and I'm not calling that HTTPAPI method.

It just strikes me as strange that the process ran for many months without this issue. Then suddenly about 6am on the 10th, it started getting the cert error on every single call. That lasted for about 3.5 hours until ops restarted the IBMi job. It then ran OK for a week, until the same thing happened about 9am on the 17th. The errors lasted about 20 minutes until ops restarted the IBMi job.

My *SRVPGM that calls HTTPAPI has always been ACTGRP(*CALLER). I changed it to run in a named activation group, and changed the caller to reclaim that activation group if the *SRVPGM reports an error. It may not help, but I don't think it could make it any worse. Thank you

[Scott Klement]

Perhaps you are experiencing memory corruption? Sometimes, by "bad luck" you happen to overwrite the area of memory that keeps track of the exit program, and sometimes you have "good luck" and you don't? That could explain it, I guess. Check all of the programs that run in this job stream to make sure all the parameters match exactly, and none are using options(*varsize) (or if they are that they are being handled properly.) If you are using pointers anywhere, check that code as well.

The other possibility is that there's a bug somewhere in the GSKit code (this is part of the operating system, not HTTPAPI). We know that the error is being returned by GSKit because HTTPAPI inserts (gskit) in front of the error message to tell us that.

I've not seen this message occur (except when expected because an exit program was in use) in the 16 years I've been doing this... but, who knows?

[jtaylor___]

Assuming I have a bug and it's showing itself by chance, it first appeared on the 10th and then again on the 17th. I'll go back and check all commits for a few weeks before the 10th, with the idea that the bug was introduced recently. thank you

[jtaylor___]

The error resurfaced yesterday, and my work-around didn't help. I've changed the work-around to do an ENDJOB instead of a RCLACTGRP. If/when the error appears again, we'll see if that works better.