On Fri, Sep 25, 2015 at 02:41:30PM -0400, Ade Lee wrote:
I'm inclined to not allow reuse of DNs until we can figure this out. If we can't, then we need to add the DELETE functionality.
I'll reinstate the previous restriction and merge the patches. Investigation of the issue and possible solutions to continue next week. For now, during testing if you really need to reuse a DN you'll have to ldapdelete the entry and delete the corresponding certificate from the NSSDB. Cheers, Fraser
Ade
On Fri, 2015-09-25 at 23:30 +1000, Fraser Tweedale wrote:
Latest patches attached. Most issued addressed; see inline for comments and ticket URLs for deferred items.
There is a problem with allowing authority DNs to be reused - when adding the cert to the NSSDB, despite what nickname you tell it to you, it will put the cert under the nickname of the existing cert with that subject DN. Thus when you go to find the cert by nickname, it cannot locate it. Failure ensues. This is possibly a bug in NSS (it's certainly surprising), but I need more time to analyse it.
I've attached an experimental (builds, but as yet completely untested with high chance of brokens) patch on top of my current patches that switches to looking up the cert by issuer DN and serial. I need to consider implications of this switch including for renewal in replicated environments. It might not be the right approach but afaict it is the only other way CryptoManager gives you to look up a cert.
Ideally we discover that NSS/JSS is doing the wrong thing with what it is doing with nicknames and we can get a fix there are move on with life.
Anyhow, other comments inline.
Thanks, Fraser
On Thu, Sep 24, 2015 at 06:26:39PM -0500, Endi Sukma Dewata wrote:
Some comments:
1. Right now the create & modify operations over non-secure URL will fail:
$ pki -d ~/.dogtag/pki-tomcat/ca/alias -c Secret123 -n caadmin ca-authority-create o=test --parent 85a2c5c2-869d-467c-9adf -dcc34367e836 ForbiddenException: No user principal provided.
It works with the secure URL:
$ pki -U https://$HOSTNAME:8443 -d ~/.dogtag/pki-tomcat/ca/alias -u caadmin -w Secret123 ca-authority-create o=test --parent 85a2c5c2-869d-467c-9adf-dcc34367e836 Authority DN: O=test ID: 14004c0f-3531-49c2-ae7a-99f715af7cc4 Parent DN: 85a2c5c2-869d-467c-9adf-dcc34367e836 Enabled: true
This can be fixed by adding <security-constraint> into the web.xml and registering it in auth-method.properties.
Thanks for this explanation. Worked a treat!
2. The "Parent DN" field in the output above should show the DN of the parent authority instead of the ID. We probably should show both Parent DN and Parent ID.
Fixed the label, filed ticket for including the Parent/Issuer DN: https://fedorahosted.org/pki/ticket/1618
3. Per discussion with alee, we need a way to find the host/main CA using something like:
$ pki ca-authority-show --host-authority
Done.
4. I think we also need a way to translate a DN into ID:
$ pki ca-authority-show --dn <DN>
Filed ticket: https://fedorahosted.org/pki/ticket/1617
5. Also per discussion with alee, the authority DN should be unique only among active CAs. So you should be able to create a CA, disable it, then create another one with the same DN. If you try to enable the old CA it should fail. This can be implemented later.
Per discussion above, implemented, but breaks your CA if you try it!
6. In AuthorityData.java the @XmlRootElement probably should be changed to "authority" for consistency. Also the following fields can be renamed because the "a" is redundant: * aid -> id * parentAID -> parentID I think the XML output will look better that way.
Done.
7. The method description in ISigningUnit.java doesn't match the method name (public vs. private).
Fixed; well spotted.
I think these are not difficult to fix, and once fixed it should be sufficient to push as initial implementation, so consider this a conditional ACK (unless alee has other comments). Item #5 (or #4 too) can be implemented later.
I also created this page to document the CLI: http://pki.fedoraproject.org/wiki/PKI_CA_Authority_CLI Feel free to expand it further.
Thanks a bunch; I will review this Monday. This also reminds me to spend some time updating the design pages as well - there have been many changes!