Hi Scott
We have been successfully sending data using and http_url_post for several years, but it has recently stopped working - examining the logs, it seems that it is sending our default certificate rather than the one that is assigned to the application id that we are specifying int he https_init and we are consequently being refused when the post is performed with an SSL certificate error.
Any assistance would be appreciated.
Regards
ChrisW
https_init not picking up certificate?
Re: https_init not picking up certificate?
We have whittled this down to being an authority problem - the correct certificate is picked up when the job is called interactively under a developer's profile, but fails when being run in the standard batch job which runs under a "runtime" profile.
Can anyone suggest what authority level is required, or what authority to which specific objects, might be causing the problem?
Thanks in advance for any assistance!
ChrisW
Can anyone suggest what authority level is required, or what authority to which specific objects, might be causing the problem?
Thanks in advance for any assistance!
ChrisW
Re: https_init not picking up certificate?
New theory:
Certificate is being picked up just fine!
However, we have up to three calls to different endpoints in the same job stream for the same transaction, depending on the set up of the particular customer.
The failing call is on the middle of these calls.
If the first call is made, the second call fails because it hangs on to the previous (default) certificate.
If the first call is not made the second call picks up the correct certificate and runs fine.
We are issuing an https_init(<certificate name>) before setting up the data and calling the http_url_post - is there anything else we should be doing to reset the environment and ensure that the certificate is sent correctly?
Edit: I found some notes in another thread about calling https_cleanup and have added that, but the results are still the same.
Further Edit: Interestingly, the Debug Logs created for the second call are written to the same file as the logs for the first call, despite a specific location (separate folder) being specified for each call.
Thanks in advance for any assistance!
Chris W
Certificate is being picked up just fine!
However, we have up to three calls to different endpoints in the same job stream for the same transaction, depending on the set up of the particular customer.
The failing call is on the middle of these calls.
If the first call is made, the second call fails because it hangs on to the previous (default) certificate.
If the first call is not made the second call picks up the correct certificate and runs fine.
We are issuing an https_init(<certificate name>) before setting up the data and calling the http_url_post - is there anything else we should be doing to reset the environment and ensure that the certificate is sent correctly?
Edit: I found some notes in another thread about calling https_cleanup and have added that, but the results are still the same.
Further Edit: Interestingly, the Debug Logs created for the second call are written to the same file as the logs for the first call, despite a specific location (separate folder) being specified for each call.
Thanks in advance for any assistance!
Chris W
Re: https_init not picking up certificate?
Talking to myself again! But the resolution might be useful to others!
It seems that our programs were compiled with DFTACTGRP(*NO), but no specific activation group specified. This seems to cause problems for the https_init, and the http_debug functions, as we saw evidence of the wrong certificate being used and debug logs being written to the wrong place despite the apparent success of the call (return code = 0).
Adding a unique activation group to each of the programs called within the job has fixed the issue and we are now running happily, having learned the valuable lesson of not assuming that code written 20 years ago had been thoroughly understood or tested at the time it was implemented!!!
It seems that our programs were compiled with DFTACTGRP(*NO), but no specific activation group specified. This seems to cause problems for the https_init, and the http_debug functions, as we saw evidence of the wrong certificate being used and debug logs being written to the wrong place despite the apparent success of the call (return code = 0).
Adding a unique activation group to each of the programs called within the job has fixed the issue and we are now running happily, having learned the valuable lesson of not assuming that code written 20 years ago had been thoroughly understood or tested at the time it was implemented!!!
-
Scott Klement
- Site Admin
- Posts: 872
- Joined: Sun Jul 04, 2021 5:12 am
Re: https_init not picking up certificate?
What version of HTTPAPI are you running?
Are you calling https_cleanup() to clean up the previous certificate settings?
If you're running the current version of HTTPAPI, just calling https_init() explicitly at the start of your program should automatically clean up the previous cerificate settings as well.
It does not matter which activation group you are using, as long as you are using a genuine activation group. (i.e. not using actgrp(*caller) and then calling it from the OPM "default" activation group.) Specifying DFTACTGRP(*NO) without a specific activation group will work fine. (That runs in an activation group called QILE.)
Are you calling https_cleanup() to clean up the previous certificate settings?
If you're running the current version of HTTPAPI, just calling https_init() explicitly at the start of your program should automatically clean up the previous cerificate settings as well.
It does not matter which activation group you are using, as long as you are using a genuine activation group. (i.e. not using actgrp(*caller) and then calling it from the OPM "default" activation group.) Specifying DFTACTGRP(*NO) without a specific activation group will work fine. (That runs in an activation group called QILE.)
Re: https_init not picking up certificate?
Thanks for the response, Scott!
We have the same function running on three iSeries boxes and I now have it working as expected on two of the three.
Looking at the logs, I now notice that the server that it is not working correctly on is running a way older version:
Bad Box: HTTPAPI Ver 1.23 released 2008-04-24
Good Boxes: HTTPAPI Ver 1.32 released 2016-02-10
However, we do seem to have a complicated combination of software installed on the various boxes - and no-one still with the company has any memory of why this has happened.
For instance, we have a total of three versions of the EXPAT service program and binding directory (in LIBHTTP, LIBEXPAT and HTTPAPI) all have different object creation dates.
I have been compiling with LIBHTTP in the library list, but the job description being used at runtime contains both LIBHTTP and LIBEXPAT.
Looking at the programs on our system with compile notes in the source, some contain a programmer's instruction to use LIBHTTP and others to use LIBEXPAT, so I am at a bit of a loss on how to go forward without risking breaking anything else that is currently "accidentally" working, even though it may be incorrectly set up or compiled.
We have the same function running on three iSeries boxes and I now have it working as expected on two of the three.
Looking at the logs, I now notice that the server that it is not working correctly on is running a way older version:
Bad Box: HTTPAPI Ver 1.23 released 2008-04-24
Good Boxes: HTTPAPI Ver 1.32 released 2016-02-10
However, we do seem to have a complicated combination of software installed on the various boxes - and no-one still with the company has any memory of why this has happened.
For instance, we have a total of three versions of the EXPAT service program and binding directory (in LIBHTTP, LIBEXPAT and HTTPAPI) all have different object creation dates.
I have been compiling with LIBHTTP in the library list, but the job description being used at runtime contains both LIBHTTP and LIBEXPAT.
Looking at the programs on our system with compile notes in the source, some contain a programmer's instruction to use LIBHTTP and others to use LIBEXPAT, so I am at a bit of a loss on how to go forward without risking breaking anything else that is currently "accidentally" working, even though it may be incorrectly set up or compiled.
-
Scott Klement
- Site Admin
- Posts: 872
- Joined: Sun Jul 04, 2021 5:12 am
Re: https_init not picking up certificate?
Both of the versions you list are very out of date. Please update them all to the current version.
I don't know any reason why you should have multiple versions of either HTTPAPI or EXPAT. I will say that it is commonplace to have a version of Expat installed into the HTTPAPI library because this allows better integration between them. But I would only have it installed once. Perhaps have LIBHTTP with the current version of both HTTPAPI and EXPAT.
The versions are all backward compatible, so there's no value in running an older version. Always run the latest versions to have the latest bug and security fixes installed.
I don't know any reason why you should have multiple versions of either HTTPAPI or EXPAT. I will say that it is commonplace to have a version of Expat installed into the HTTPAPI library because this allows better integration between them. But I would only have it installed once. Perhaps have LIBHTTP with the current version of both HTTPAPI and EXPAT.
The versions are all backward compatible, so there's no value in running an older version. Always run the latest versions to have the latest bug and security fixes installed.