HTTP Protocol Port set to 0 gives http://pki.domain.tld:0/Crl/etc

[avdpas]

i think i am doing something wrong.
I am running UCM behind a NGinx proxy manager and that works fine.
For the HTTP port i wanna use the normal poort 80, so i tried setting it to 80 but i get an error saving that should be between 1024 and ...... and to turn it to 0 to disable it (needs restart so i did)

Then when i make a certificate , the CRL url is http://pki.domain.tld:0/crl/.........
When using a :0 port in an url , my says that that url is restricted.

why is the :0 there? any1 have any clue what i am doing wrong ?

[Hemsby]

Thanks for the report, this isn't something you did wrong. I looked into it and found the cause: when the HTTP protocol port is 0 (listener disabled) and the Protocol Base URL has no port, UCM falls back to the listener port and writes :0 into the CRL/OCSP/AIA URLs. I reproduced it on a test instance and opened a fix in #434, which uses the default port 80 in that case.

Until it's released, you can work around it by setting the Protocol Base URL to http://pki.domain.tld:80. An explicit port is honoured, and :80 is left out of the generated URLs, so you get http://pki.domain.tld/crl/.... Certificates you already issued will keep the :0, so reissue them after changing it.

[NeySlim]

@avdpas one correction and one addition to the answer above.

Your existing CAs also need fixing. The CRL, OCSP and AIA URLs are stored on each CA when it is created and copied into every certificate it issues. Changing the Protocol Base URL, or installing the fix from #434, does not update them, so reissuing alone will still produce :0.

1. Set the Protocol Base URL to http://pki.domain.tld:80.
2. For each affected CA, open the CRL/OCSP page and look at its CDP, OCSP and AIA URLs. Remove any that contain :0 and add the same URL without it.
3. Reissue the certificates that carry :0. If an intermediate CA's own certificate carries its parent's :0 URL, that needs reissuing too.

The port setting. The HTTP Protocol Port is the port UCM itself listens on, not the one it advertises. The 1024 minimum is intentional: the service does not run as root, so it cannot bind port 80. The usual setup is to leave it at 8080 and point your proxy at that port, with :80 in the Protocol Base URL, so clients see http://pki.domain.tld/....

Port 0 also works, but it turns that plain HTTP listener off, so your proxy must then reach these endpoints on UCM's HTTPS port.

[avdpas]

first of all let me state that i am amazed on how quickly i got a reply..... completely awesome.
Fortunately i am at the stage of setting up UCM , and i found out when creating my root ca. So i will just recreate the root ca cert and continue testing how to set everything up.
I can confirm that setting the base ure including port number already in the configuration page looks ok.
looking forward to the release wit the fix implemented.

I stumbled on to this amazing piece of software when looking for a PKI for my homelab. There are hardly any pieces of software out there that fit a modern homelab where automation and the option for manual creation meet. As well having a proper gui.
This software is the first that ticks all the boxes and is way easier to configurate and install then many others i have tried.... and i tried many :)

thanks for this great project!

[NeySlim]

Thank you so much for the warm words :)

[Hemsby]

Following NeySlim's correction above, here is the full fix for your existing setup. The URLs are stored on each CA and copied into its certificates, so besides setting the Protocol Base URL to http://pki.domain.tld:80 you also need to correct each CA's URLs on the CRL/OCSP page and then reissue the certificates that carry :0. Once #434 ships, upgrading will remove the :0 from the stored CA URLs for you, so only the reissue step remains.

[NeySlim]

Shipped in v2.249, fixed by #434 from @Hemsby. With the HTTP protocol port set to 0 and a Protocol Base URL without a port, CRL, OCSP and AIA URLs now use port 80, and the upgrade corrects the URLs stored on each CA.

Certificates issued before the upgrade keep :0 in their URLs, so they need reissuing.