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!
--
Endi S. Dewata