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
midrange.com
