I suspect I’ll have to access PKIAAS through something like :80 and create a new root CA so the sub CA will end up with the following CRLDP URI: http://<fqdn>/se/crl/1.
Otherwise, how could I define arbitrary URL for CRL?
Is there a way to specify an URL for OCSP too?
I guess the use case “Certify external CA” is currently not well supported.
We have a feature on the ToDo list to add better profile support for certificate issuing. We should add options to handle those corner cases.
In the meantime you could use a custom service request. The portal has a plug-in mechanism, that allows to intercept existing workflow processing. We use that in our own portal to auto-approve certificate requests for the DevNetCA.
I suspect I’ll have to access PKIAAS through something like :80 and create a new root CA so the sub CA will end up with the following CRLDP URI: http://<fqdn>/se/crl/1.
I tried that and it didn’t work, the new URL is: http://localhost:8080/se/crl/2
My understanding is that certificates are systematically issued with an unreachable URI for certificate validation, so there is basically no revocation possible when using standard service requests. If I am correct, how is this a corner case?
In the meantime you could use a custom service request.
Do you have pointers on how to do that, by any chance?
Indeed, after setting the ServerURL and rebuilding the image we get a usable URI. Even if the URI can not be set arbitrarily, that is enough to unblock us.
We updated docker-compose.yml to mount the configuration file as a read-only volume, so we don’t have to run the deploy script on configuration changes.