Installing ACME with pkispawn breaks pki-tomcat instance with a cert that is not created.

[wmerkens]

Fedora 42 server
Dog tag pki 11.7.0.1

After my issues with OCSP, I shifted to 11.7, and that problem got solved, see #5177

I attempted to install the ACME module, but ran into issues.

Using the steps in this doc https://github.com/dogtagpki/pki/wiki/Installing-ACME-Responder-using-pkispawn

It shows this step

    -f /usr/share/pki/server/examples/installation/acme.cfg \
    -s ACME \
    -D acme_database_url=ldap://ds.example.com:3389 \
    -D acme_issuer_url=https://pki.example.com:8443 \
    -D acme_realm_url=ldap://ds.example.com:3389

First problem, the port 3389 is the RDP port; it should be port 389, which is the LDAP port.

If we then look at acme.cfg, the default template file.

[DEFAULT]
pki_server_database_password=Secret.123
pki_cert_chain_nickname=ca_signing

[ACME]
pki_sslserver_nickname=sslserver

acme_database_type=ds
acme_database_url=ldap://localhost.localdomain:3389
acme_database_bind_password=Secret.123

acme_issuer_type=pki
acme_issuer_url=https://localhost.localdomain:8443
acme_issuer_password=Secret.123

acme_realm_type=ds
acme_realm_url=ldap://localhost.localdomain:3389
acme_realm_bind_password=Secret.123

Why are we specifying the URLs through the -D to pkispawn when they are in the acme.cfg

Now, of course, I edit the cfg to more correctly represent my layout

[DEFAULT]
pki_server_database_password=secret-password
pki_cert_chain_nickname=caSigningCert cert-pki-tomcat CA

[ACME]
pki_sslserver_nickname=Server-Cert cert-pki-tomcat

acme_database_type=ds
acme_database_url=ldap://dog-tag-pki.userful.ca:389
acme_database_bind_password=secret-password

acme_issuer_type=pki
acme_issuer_url=https://dog-tag-pki.userful.ca:8443
acme_issuer_password=secret-password

acme_realm_type=ds
acme_realm_url=ldap://dog-tag-pki.userful.ca:389
acme_realm_bind_password=secret-password

You can see that I adjusted the first three key settings, removed sslserver, and corrected the ports and URLs.

First, this worked for the ports change, but not for pki_sslserver_nickname

For some reason, it keeps using sslserver. I can see the CSR for it in /etc/pki/pki-tomcat/certs.

But this cert never gets created and installed in the nssDB, so when you restart, you get this error

pki-server[11177]: ERROR: Certificate chain not found: sslserver

And since the tomcat is now in an unstartable state, you cannot do the following

pkidestroy -s ACME

To get rid of the bad instance, I ended up making a dummy sslserver cert to just get the pki-tomcat to start which then let me get rid of ACME. This was not perfect since installing that dummy cert caused pki-tomcat to think that it was the root signing cert and broke the site's SSL.

Also, I was forced to use the -D options since it did not listen to the acme.cfg properly and seemed to ignore the specified URL lines.

pkispawn -f acme.cfg -s ACME -D acme_database_url=ldap://dog-tag-pki.userful.ca:389 -D acme_issuer_url=https://dog-tag-pki.userful.ca:8443 -D acme_realm_url=ldap://dog-tag-pki.userful.ca:389

I ended up restoring a backup that I had to a state before I installed ACME.

I am stuck. I have tried a few ways to get around the sslserver cert that does not exist. I feel it's hard-coded somewhere, and why is a CSR created for it, but it is never actually created.

[fmarco76]

Hi @wmerkens

It shows this step

    -f /usr/share/pki/server/examples/installation/acme.cfg \
    -s ACME \
    -D acme_database_url=ldap://ds.example.com:3389 \
    -D acme_issuer_url=https://pki.example.com:8443 \
    -D acme_realm_url=ldap://ds.example.com:3389

First problem, the port 3389 is the RDP port; it should be port 389, which is the LDAP port.

389 is the default port but you can use other ports like in this case with 3389.

If we then look at acme.cfg, the default template file.

[DEFAULT]
pki_server_database_password=Secret.123
pki_cert_chain_nickname=ca_signing

[ACME]
pki_sslserver_nickname=sslserver

acme_database_type=ds
acme_database_url=ldap://localhost.localdomain:3389
acme_database_bind_password=Secret.123

acme_issuer_type=pki
acme_issuer_url=https://localhost.localdomain:8443
acme_issuer_password=Secret.123

acme_realm_type=ds
acme_realm_url=ldap://localhost.localdomain:3389
acme_realm_bind_password=Secret.123

Why are we specifying the URLs through the -D to pkispawn when they are in the acme.cfg

The option -D is used to overwrite the option in the configuration file, they have different values. You can edit the file or add the option. In this case the default file is used with some customisation which are made explicit.

For the installation problem. Is this a shared instance with other subsystems or ACME only?

[wmerkens]

Yes, it was in the system with CA and OCSP already running.

As I mentioned, I adjusted the cfg file, and my version of acme.cfg is now there, but it's not working. I also have a larger pki_instance.cfg file that includes all the options for all the modules, which I used for the CA and OCSP installations, and it works. When I updated the [ACME] section in that file, it also failed to listen to the entries, so I reduced it to a very basic config based on the sample acme.cfg.

So my entries in acme.cfg are the same as the -D options. One thing I did not mention is that I also tried this option with the other -D options I used, which was -D pki_sslserver_nickname="Server-Cert cert-pki-tomcat" to see if I could override the use of sslserver.

[kimettog]

Created IDM-3449

[wmerkens]

I found a way around this problem.

From my working CA/OCSP system, I found in /etc/pki/pki-tomcat/certs the sslserver.csr request file.

Before I tried another install, I submitted the sslserver.csr to my CA, created a cert and approved it in the web interface.

I then saved the cert as sslserver-crt.pem

I then used certutil to add it to the default nssDB

certutil -A -d /etc/pki/pki-tomcat/alias/ -n "sslserver" -t "u,u,u" -i sslserver-crt.pem

Then I used the pkispawn with my acme.cfg to do another install

pkispawn -f acme.cfg -s ACME -D acme_database_url=ldap://dog-tag-pki.userful.ca:389 -D acme_issuer_url=https://dog-tag-pki.userful.ca:8443 -D acme_realm_url=ldap://dog-tag-pki.userful.ca:389

I then did a test by restarting the Tomcat server.

systemctl restart pki-tomcatd@pki-tomcat.service

And everything is working well; all three components now appear to be functioning correctly.

I now need to use certbot to sign in and request a cert.