Hi all,
I'm using EJBCA to configure a publisher (Microsoft AD Publisher) and see in the EJBCA documentation that :
Once created, a Publisher is active when it has been selected in a CA or a Certificate Profile.
The situation is, I would like to configure my CA that whenever an end entity certificate is enrolled by this CA, the issued certificate will be published to my Microsoft Active Directory server.
In order to do that, first I need to create an AD Publisher. The problem is:
When I configure my CA to use the created AD Publisher (see the adpublisher.png) => the enrolled certificate doesn't publish to AD server. Seem like the one that we configured to CA is for CRL publisher only.
There is no problem with my AD connection or AD Publisher configuration, because when I set the AD publisher used by Certificate Profile => the certificate is published to AD server successfully.
Then I think the configuration of AD Publisher in Edit Certificate Authority screen is not work for certificate publication, it can be done via Certificate Profile only.
By right, it should support to publish user certificate to AD Publisher individually to each CA, not just Certificate Profile. Please tell me if i was wrong something
Hi! You conclusion is correct. In order to publish certificates, your Publisher has to be selected under the relevant Certificate Profile. The Publisher selected in CA settings applies to CRL publishing only.
If it is the case, then we will be in trouble when integrating with multiple AD Server.
For example: I'm providing Certificate Authority for two different customers: A and B and both of them request me to publish their user certificate to the appropriate AD Server A and B.
Then in this case, I've to create two different Certificate Profiles just to publish user certificate to proper AD Server. It will become massive because in most case, my customer might request different Certificate Profile for different purposes such as: Code Signing, Document Signing, SSL Serve ... Then I've to manage a very large amount of certificate profiles - that I never want to.
Right, you are concerned about doubling the number of profiles with customer A and B in your case. If you expect to run a larger multi-customer environment there will be more...
On the other hand, to achieve true role separation between your customers, where they can even have their own, completely separate sub-administrators, this will be needed in order to not risk leaking any information between them.
In the long run it may also be safer to actually duplicate profiles sine changes done to one customer will no affect another customer, something you will always risk if you share profiles between different customers. In our experience organizations over time will many times invent tweaks that they want, that the other customer likely does not want.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
I'm using EJBCA to configure a publisher (Microsoft AD Publisher) and see in the EJBCA documentation that :
The situation is, I would like to configure my CA that whenever an end entity certificate is enrolled by this CA, the issued certificate will be published to my Microsoft Active Directory server.
In order to do that, first I need to create an AD Publisher. The problem is:
When I configure my CA to use the created AD Publisher (see the adpublisher.png) => the enrolled certificate doesn't publish to AD server. Seem like the one that we configured to CA is for CRL publisher only.
There is no problem with my AD connection or AD Publisher configuration, because when I set the AD publisher used by Certificate Profile => the certificate is published to AD server successfully.
Then I think the configuration of AD Publisher in Edit Certificate Authority screen is not work for certificate publication, it can be done via Certificate Profile only.
By right, it should support to publish user certificate to AD Publisher individually to each CA, not just Certificate Profile. Please tell me if i was wrong something
Last edit: SMVN 2022-07-11
Uppp, can someone help to answer my concern?
Hi! You conclusion is correct. In order to publish certificates, your Publisher has to be selected under the relevant Certificate Profile. The Publisher selected in CA settings applies to CRL publishing only.
For future discussions, please refer to the EJBCA discussion pages on Github
Thanks for your update!
If it is the case, then we will be in trouble when integrating with multiple AD Server.
For example: I'm providing Certificate Authority for two different customers: A and B and both of them request me to publish their user certificate to the appropriate AD Server A and B.
Then in this case, I've to create two different Certificate Profiles just to publish user certificate to proper AD Server. It will become massive because in most case, my customer might request different Certificate Profile for different purposes such as: Code Signing, Document Signing, SSL Serve ... Then I've to manage a very large amount of certificate profiles - that I never want to.
I believe we can avoid that by allowing publishing user certificate via Certificate Authority configuration. And I saw in primekey documentation, in pointed out that we can activate the publisher via Certificate Authority configuraiton
https://doc.primekey.com/ejbca/ejbca-operations/ejbca-operations-guide/ca-operations-guide/publishers-management
Last edit: SMVN 2022-07-21
Right, you are concerned about doubling the number of profiles with customer A and B in your case. If you expect to run a larger multi-customer environment there will be more...
On the other hand, to achieve true role separation between your customers, where they can even have their own, completely separate sub-administrators, this will be needed in order to not risk leaking any information between them.
In the long run it may also be safer to actually duplicate profiles sine changes done to one customer will no affect another customer, something you will always risk if you share profiles between different customers. In our experience organizations over time will many times invent tweaks that they want, that the other customer likely does not want.