Re: Automate Certificate Renewal for DCM and Apache HTTP application

Your detailed explanation is much appreciated.

Jim

On Sun, Apr 26, 2026 at 7:01 AM Patrik Schindler <poc@xxxxxxxxxx> wrote:

Hello Jim,

Am 25.04.2026 um 17:34 schrieb Jim Franz <franz9000@xxxxxxxxx>:

Found this - https://ibmi-oss-docs.readthedocs.io/en/latest/certbot.html

- my first read is its many steps beyond my training.

Looking for a simple solution to renewing SSL cert - having to train

network staff with no IBM i experience.

The topic about automatic certificate renewals pops up frequently lately.
Yet, IBM seems to refuse to integrate helpful automatisms into their
operating system because of alleged security concerns, if I remember
correctly. As far as I'm aware, there is no "simple" solution yet.

Certbot was developed with Linux distros in mind. Certificate handing
couldn't be easier there: The plain root certificates (and keys, if you
need your own certs/keys) are laid out in /etc/ssl as simple files and —
for manual additions — in /usr/local/share/ca-certificates. The OpenSSL
shared library ("service program") — the cryptographic base software used
in the majority of software running on Linux — takes care of utilizing the
simple directory based layout. There's nothing complicated here for an
administrator. Because it's all files, adding and removing certificates
automatically is extremely easy.

Other operating systems like IBM i, macOS, and Windows, as well as the
Java world utilizes so called certificate stores, which are by far less
transparent. In addition, often it's not clear which "drawer" of these
stores needs to be chosen for saving a given certificate, unless one really
sits down and analyzes the documentation. On top comes term confusion.
Often the generic term "certificate" is applied to a private key and
certificate in one container file. Add the technical designations of
PKCS#12 and PEM, bring in the Windows somewhat arbitrary three-char
extensions for them. Very messy.

In short: One generates two files tied to each other by mathematics. One
of these is the private key which has to be kept secret. The other is a
certificate request. This has to be approved by another entity through
"signing" it, adding a digital signature. Only then, this is a proper
certificate which can be distributed. This signing process also establishes
a hierarchy until a root certificate is reached, which is by definition
self-signed. This is how certificates basically work.

I assume the certificate store stuff was done because of the systems'
heritages. They use their own cryptographic APIs for applications.
Regarding IBM i, presume, Apache also is "patched" to use the IBM i crypto
API instead of OpenSSL.

Certbot is a relatively simple Python construct which has some hooks
available to remotely steer certain software, such as Apache or Nginx, but
also contains a simple web server by itself, so certificates can be
obtained without the use of any external server software. Certbot creates a
key and request pair with OpenSSL, and submits the request to the Let's
Encrypt CA for signing.
Problem is: How to prove that the requested certificate signing request is
valid? The Let's Encrypt CA uses a protocol called ACME to connect back via
http and https to the DNS name being sent with the certificate signing
request. It tries to fetch files being ephemerally being created by Certbot
in a subdirectory called .well-known. If this is successful, that proves
that the certificate requestor controls the server in question, and very
likely also DNS. Then, Let's Encrypt sends back the signed certificate
request, and Certbot puts the result in /etc/letsencrypt.
There is also the possibility to have Certbot add a certain ephemeral DNS
record to DNS instead of have Let's Encrypt checking for the existence of
files with a certain content for approval.

The biggest hurdle on non-unix systems regarding Certbot is: How to
automatically get the certificate file and accompanying key (both in PEM
format) into the respective certificate store, maybe overwriting existing
ones with the name name (Common Name tag), and tell applications using
those certificates to load the new ones from the respective store. This has
been an utterly brittle process on Windows with IIS and Exchange for years
and still feels botched. There is apparently a similar botchy solution to
automate this integration for IBM i, according to the link you've sent.

I hope this write-up clarifies the challenges you face a bit. If you feel
you lack training, I'm sure someone on this list will help your firm's case
for a fee, if you ask nicely.

Pete Helgren had links to a Tomcat solution, but i need for updating the

DCM and an Apache webserver application.

Sounds like taking a sledgehammer to crack a nut.

Is the above solution a good way to go?

I assume so, yes. Unless IBM can be pestered to implement the ACME
protocol themselves, in a solution providing proper and seamless
integration with their DCM and Java Cert store infrastructure.

:wq! PoC

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.