Feedbacks after first install and some use

[j2r2k2]

CRL

1. Delta's have a publish interval which is configurable, that would be good if base CRL publish interval is also configurable (instead of default 7 days)
2. For both validity and publish intervals should not be correlated. In my point of view, if the validity of the CRL is a bit greater than the publish interval that gives a grace period (example CRL valid for 2 days but publish every day) add a NEXT PUBLISH in metadata for display
3. Choice of the signature algorithm
4. Be able to use port 80 instead of 8080 for CRL/OCSP/CA
5. Don't use id of the CA for the CRL file name (I know the why about security but URL is in the cert so...) it is way difficult to know which crl is what.

Skew time

1. For all validities, not before could be pushed a bit before to help mitigate clock skew (like 10-20 minutes)

CA

1. AIA Certification Authority Issuer (1.3.6.1.5.5.7.48.2) is not added in a SubCA even though I added it in the Root CA before creating the SubCA. It is added in endpoint certs

Cert

1. If I issue a cert using a template from certificate menu:
   I don't see the counter updated in template menu (all are zero)
   The signature I configured in the template (digest) is not honored, default to SHA256 (RSA or ECDSA depending on the CA key type)

A long list sorry but the work already done is amazing, I am trying to adopt it for replacing 6 MS ADCS CAs in my lab.
I work for Cisco in CyberSecurity Professional Services and we are using certificates a lot in all flavours.
Really appreciate this.

[j2r2k2]

Yes sure feel free to split as there are easy adds and some that requires more work to be done.

Also, I don't know why but port 8080 HTTP now redirect me to HTTPS 8080...

Some other feedbacks:

Certificate menu

1. Possibility to change the description of a certificate
2. Add a field "friendly Name" to a cert (modifiable) as for example for OCSP responder you could have as much cert as CA you host but all got same CN. Not easy to remember which one the the correct one to map to OCSP responder.
3. Add a column "template used"

CA

1. Possibility to create a CA for more than 20years (add custom and/or Validity Period as a date like in certificate) -> for lab it is OK...

[NeySlim]

Thanks @fredlubrano , but I think discussions shouldn't be handled by agents. I appreciate the energy and the triage is technically accurate, but product direction stays with me. Please stop announcing decisions on my behalf (100 year CAs, per CA transport, port 80) and please stop stacking batches into #208. A PR with 3000 lines, 60 files and three migrations is not reviewable and will not be merged as is. Split it into small, independent PRs: the template digest bug, the usage counter, the CRL scheduling. Anything that changes product behavior waits for an explicit decision here first.
Don't be wrong, I really appreciate your contributions.

@j2r2k2 this is exactly the feedback I want, thank you. Where I stand on your list:

Confirmed bugs, will be fixed in the next release: the template digest not being honored on issuance, and the template usage counter stuck at zero. The 8080 redirect needs a repro first, protocol endpoints are supposed to stay plain HTTP, if you can run curl in verbose mode against the HTTP URL and share who issues the 3xx that would help.

Accepted enhancements: CRL validity decoupled from the publish interval with a visible next publish, that is the right model and it matches how ADCS operators think. Configurable CRL signature digest too. Readable CRL filenames will go in the download header only, URLs keep the refid since they are embedded in issued certificates.

NotBefore backdating makes sense and will land as a small fixed offset, not another setting.

Port 80 is an ops topic. UCM runs unprivileged, so bind capability via systemd or a reverse proxy is the way, I will document it rather than add code.

CAs beyond 20 years go against the safe defaults philosophy of this project. I may allow it behind an explicit opt in for lab use, decision when I am back.

Friendly name and editable description are legitimate. The friendly name touches the data model and every localization, so it goes on the roadmap rather than in a quick fix.

Last thing: I am away from the 24th for about ten days. Nothing merges while I am away. Small focused PRs for the confirmed bugs have a good chance to land before then.

[j2r2k2]

CRL readable is not mandatory but when you have 10s of CAs it becames unmanageable to remember.
Maybe don't change the current behavior but make it optional to chose the filename format when you create a new CA?
For the Port 80 bind understood, proxy is the way to go with custom URL.
CAs beyond 20 years -> Maybe create a toggle button in Settings to enable "lab mode" to ease a bit on security?

issue with redirection HTTP to HTTPS on port 8080 is a browser issue forget about it. it works in private or on another browser, I will sort it out.

This product is amazing, I have tested all the free PKI/cert manager and none are at this level, with some more tweaking and feedback it will definitely replace all the PKIs I use.

Also, it would be great if someone can present this product to our Lab communities in Cisco, I am not the only one who need PKI and it is becoming more and more useful as we progress into short time certs leading to more automation. We are implementing ACME in our products so it could help.

Some more feedbacks:

Dashboard

1. If we have a friendly Name for Cert, then prefer to display this info instead of CN (Next Expirations & Recent Certificates)

CA

1. when you create a CA, and select CA Type "Intermediate CA" the Parent CA Must only propose CA with "Path Length Constraint" > 0, I tried with a CA with Path Length Constraint=0 and it worked, CA is signed and created. This Must not be possible "Path Length Constraint" Must be enforced and generate an error or don't permit to select those CAs

Big Ask

1. Replace ADCS for windows autoenrollement (Domain controller kerberos, EAP certificate, remote desktop, etc.)

[NeySlim]

@j2r2k2 update: everything I validated from your list is now implemented on dev and will ship in the next release (2.195).

Your two bugs
The template digest is now honored at issuance (it was hardcoded to SHA-256), the template link is persisted on the issued certificate, and the templates page shows a live usage counter.

CRL
Validity and publish cadence are now decoupled per CA, with the next publish visible in the CRL metadata and in the CRL and OCSP page. The CRL signature digest is configurable (SHA-256/384/512). Publishing more often than the validity window gives you the grace period you described. Downloads now suggest a readable filename built from the CA name; the URLs keep the internal id since they are embedded in issued certificates.

notBefore
All issuance paths now backdate notBefore by a fixed 15 minutes, notAfter stays anchored on the requested validity.

Port 80
Documented in the admin guide: systemd bind capability, reverse proxy, or Docker port mapping. No code needed, the port was already configurable.

Still open
The friendly name, editable description, template column and long validity CAs wait for my return as discussed. For the 8080 HTTP to HTTPS redirect, I still need a repro: can you curl the HTTP URL with verbose output and share who issues the 3xx, and tell me whether anything sits in front of UCM?

Thanks again for the quality of this feedback, it moved fast because it was precise.

[j2r2k2]

Thanks a lot for the efforts.
I think you missed my previous message just upper.
HTTPS redirect was a browser issue, nothing to be followed.
CRL URLs -> Can we add a toggle to chose when we create the CA between ca_ref_id and ca_name? When you have 10s of CAs, remembering CA paths is kind of challenging with IDs... (We often need to configure manually the CRL/OCSP paths in our products)

[NeySlim]

Ah yes, I missed it ...

[NeySlim]

I implemented a toggle at CA creation and now working on post creation toggle. Will be in next release.