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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]> 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 <[email protected]>
> >>> 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: [email protected]
> >>>>> To subscribe, unsubscribe, or change list options,
> >>>>> visit: https://lists.midrange.com/mailman/listinfo/web400
> >>>>> or email: [email protected]
> >>>>> 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: [email protected]
> >>>> To subscribe, unsubscribe, or change list options,
> >>>> visit: https://lists.midrange.com/mailman/listinfo/web400
> >>>> or email: [email protected]
> >>>> 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: [email protected]
> >>> To subscribe, unsubscribe, or change list options,
> >>> visit: https://lists.midrange.com/mailman/listinfo/web400
> >>> or email: [email protected]
> >>> 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: [email protected]
> >> To subscribe, unsubscribe, or change list options,
> >> visit: https://lists.midrange.com/mailman/listinfo/web400
> >> or email: [email protected]
> >> 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: [email protected]
> To subscribe, unsubscribe, or change list options,
> visit: https://lists.midrange.com/mailman/listinfo/web400
> or email: [email protected]
> 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: [email protected]
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: [email protected]
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.