× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. WEB400
  3. September 2021

Re: HTTPS problems after latest PTF update.

Whenever I apply a new cert (I have quite a few customers who would rather
pay me to do it than learn haha) I always stop and restart the server,
refresh the page and double check the expiration date. I just did one
today in fact. Your email reminded me I had a couple days left on one
customer's system. :)

On Mon, Sep 13, 2021 at 3:33 PM Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

Just to complete the record ... we solved our problem.

The PTFs themselves had nothing to do with it. What caused it was the
subsequent IPL which restarted the HTTP servers.

Basic cause was that I renewed our SSL certificate earlier this year
(June?) and it all seemed to work just fine and the SSL functionality was
uninterrupted.

At the time I did the update the "old" certificate was still valid. It
appears as if, even though it expired in the meantime, because there was a
valid certificate available (the renewal one) the fact that the web apps
were assigned to the old cert did not matter. As long as we did not restart
the server anyway.

When we did the IPL and restarted the HTTP server, PHP made specific
checks for the cert and noted that it was out of date. As a result it would
not enable HTTPS functionality and nothing worked.

Brad mentioned an issue with outdated certs causing weird errors, so I
deleted all the out-of-date certs. This time when the server was restarted
PHP said there was no cert associated. That was the first hint. If there
was now no association I must have deleted one along with the expired cert.

As a temporary measure I removed the configuration includes that defined
the SSL and the web site came to life - but of course without any pages
that needed SSL.

Used the DCM to connect the SSL application to the new certificate.
Reenabled the SSL configs and restarted the server (again). Still failed
BUT this time the log file showed only one certificate error. Second clue -
I had not associated anything with an old Blog application since we no
longer use it but its SSL configuration was still being defined.

Edited the config again to omit the Blog but leave the main SSL enabled
and VOILA! Everything works again.

So the lesson for today is ...

When you introduce a new certificate make sure to associate it with the
site - otherwise it will work for a while until ...

I confess that I am amazed that it all continued to work after the old
cert expired (which was back in July I think) but that stuff is all black
magic to me anyway.


Thanks to all who offered assistance and particularly to Brad who's idea
suppled the hint if not the solution!


Jon Paris


On Sep 13, 2021, at 1:45 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

Well it looks as if it is my old Zend Server 6 that has the issue.

The error has now changed to No certs available rather than expired ...
but I can't find what blasted app I'm supposed to assign.

That will teach me to delete expired certs without checking who was
using them!


Jon paris

On Sep 13, 2021, at 12:26 PM, Brad Stone <bvstone@xxxxxxxxx> wrote:

Make sure you check all Certificate Authorities, Server and Client
certificates and any user certificates. If I recall that's at least 3
different places in DCM you need to look.

On Mon, Sep 13, 2021 at 10:58 AM Jon Paris <jon.paris@xxxxxxxxxxxxxx>
wrote:

Had several expired ones. Got rid of all of them plus I changed the DCM
password (as per a similar issue Pete H had back in 2019) and
restarted the
HTTPS dependent servers. No change.

Also tried restarting the entire TCP HTTP server setup - no joy.


Jon Paris

On Sep 13, 2021, at 11:19 AM, Brad Stone <bvstone@xxxxxxxxx> wrote:

Jon,

Check all your certificates and CAs for expired ones. Delete any that
are
expired. This is a known IBM bug that is VERY odd.

It doesn't matter if the CA or cert has nothing to do with your
application, this error creeps up from time to time, so you have to
delete
every expired cert (client, server, user created) and CAs.

On Mon, Sep 13, 2021 at 10:05 AM Jon Paris <jon.paris@xxxxxxxxxxxxxx>
wrote:

Applied all the latest TR PTFs yesterday and today my HTTPS servers
are
all failing.

The message in the log is:

"The default key has an expired certificate or the password of key
database file has expired, error = 107."

Neither of which appear to be true as best I can tell. The DCMsays
the
cert is good thru 2022 and it was all working immediately prior to
the
update.

The problem only appears to affect HTTPS - all other web servers, web
services, etc. are all working OK.

Anyone seen this or got any ideas?


Jon Paris
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing
list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.


--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing
list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.


--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing
list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.


--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.



--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.



As an Amazon Associate we earn from qualifying purchases.

This thread ...
Replies:
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.