The latest lightweight CAs (f.k.a. Sub-CAs) patches are attached. This cut has significant changes and additions including: - CAs are now stored in a flat structure with references to parents - CAs are now identified by "AuthorityID" (which for now is a UUID underneath). Many variables, method names and user-visible strings were updated accordingly. Out with "caRef" terminology. - "Sub-CA" terminology is (mostly) out; "Authority" is in. This is to support lightweight CAs that are not descendents of top-level CA (which can be implemented later). - ca-cert-request-submit command and related client / service classes were updated to add "authority" parameter - Some more specific use of exception (including some new exception classes) to indicate / catch particular errors. - More appropriate HTTP status codes return when client has send invalid data (400), referenced unknown authority (404) or attempts to create an authority with Subject DN already uesd by another authority (409 Conflict) - LDAP entry now gets added before key generation and signing. If something goes wrong, the DB entry is removed in the catch block. There are still notable gaps in functionality that are in progress or will be implemented soon: - Audit log events - Resources to enable/disable/delete authority - Resources to access cert and pkcs7 chain of authority - Keygen params - Param to specify token on which to generate authority key Thanks, Fraser
On Mon, Sep 14, 2015 at 05:25:00PM +1000, Fraser Tweedale wrote:
The latest lightweight CAs (f.k.a. Sub-CAs) patches are attached. This cut has significant changes and additions including:
- CAs are now stored in a flat structure with references to parents
- CAs are now identified by "AuthorityID" (which for now is a UUID underneath). Many variables, method names and user-visible strings were updated accordingly. Out with "caRef" terminology.
- "Sub-CA" terminology is (mostly) out; "Authority" is in. This is to support lightweight CAs that are not descendents of top-level CA (which can be implemented later).
- ca-cert-request-submit command and related client / service classes were updated to add "authority" parameter
- Some more specific use of exception (including some new exception classes) to indicate / catch particular errors.
- More appropriate HTTP status codes return when client has send invalid data (400), referenced unknown authority (404) or attempts to create an authority with Subject DN already uesd by another authority (409 Conflict)
- LDAP entry now gets added before key generation and signing. If something goes wrong, the DB entry is removed in the catch block.
There are still notable gaps in functionality that are in progress or will be implemented soon:
- Audit log events - Resources to enable/disable/delete authority - Resources to access cert and pkcs7 chain of authority - Keygen params - Param to specify token on which to generate authority key
Latest patches attached. Along with some minor improvements to the original patches, three new patches 0048-0050 add ability to enable and disable lightweight CAs. Commit messages for the earlier patches have also been updated for consistency and to include ticket references. Thanks, Fraser
On 9/14/2015 2:25 AM, Fraser Tweedale wrote:
The latest lightweight CAs (f.k.a. Sub-CAs) patches are attached. This cut has significant changes and additions including:
- CAs are now stored in a flat structure with references to parents
- CAs are now identified by "AuthorityID" (which for now is a UUID underneath). Many variables, method names and user-visible strings were updated accordingly. Out with "caRef" terminology.
- "Sub-CA" terminology is (mostly) out; "Authority" is in. This is to support lightweight CAs that are not descendents of top-level CA (which can be implemented later).
- ca-cert-request-submit command and related client / service classes were updated to add "authority" parameter
- Some more specific use of exception (including some new exception classes) to indicate / catch particular errors.
- More appropriate HTTP status codes return when client has send invalid data (400), referenced unknown authority (404) or attempts to create an authority with Subject DN already uesd by another authority (409 Conflict)
- LDAP entry now gets added before key generation and signing. If something goes wrong, the DB entry is removed in the catch block.
There are still notable gaps in functionality that are in progress or will be implemented soon:
- Audit log events - Resources to enable/disable/delete authority - Resources to access cert and pkcs7 chain of authority - Keygen params - Param to specify token on which to generate authority key
Thanks, Fraser
Some comments: 1. The db.ldif creates ou=subCAs instead of ou=authorities. 2. Is authority DN globally unique? If that's the case it can be used as a user-friendly representation of the UUID. We'll continue to use UUID for the LDAP entry DN and REST URL, but users don't really need to see it in the CLI (except in detailed output). So the CLI output can be changed as follows: * Issuer DN/ID -> Authority DN * Parent ID -> Parent DN I think "Issuer DN" is more appropriate to be used in the context of a certificate to refer to the authority that issued the certificate. 3. Right now it's possible to create an authority with the same DN as the main CA's DN (it created the LDAP entry, but later failed due to nickname mismatch). If authority DN is unique, we shouldn't allow that. We can fix this by creating the main authority LDAP entry during installation. It's not just for fixing this issue, but all authorities (including the top-level ones) should have the corresponding LDAP entries. 4. In CertificateAuthority.createCA() if no parent is specified, the authority will be added as a subordinate of the main CA. I think adding an authority without parent should be reserved for top-level authorities which we may support in the future. For now the ca-authority-create CLI should require a parent. In #3 we're adding the main CA entry, so there's always a parent. 5. In the CLI output, if the authority doesn't have a Parent ID it shows a "null". It would be better to show "None" instead, or just don't show the Parent ID at all. 6. Assuming authority DN is unique, we can add --issuer <DN> option to these commands: * pki ca-cert-find --issuer <dn> * pki ca-cert-request-submit --issuer <dn> * pki client-cert-find --issuer <dn> * pki client-cert-request --issuer <dn> 7. I think we should store authority DN and parent DN in the LDAP entry itself. This way we don't need to rely on the nickname and NSS database to figure out the DNs. 8. Right now the authority certs & keys are stored in the NSS database. I'm not sure about the scalability & manageability (e.g. replication, orphaned keys). It might be OK for now, but if possible they should be stored (securely) in the LDAP entry itself or in KRA. We probably only need to store the certs & keys of the top-level authorities in the NSS database. 9. To support paging in AuthorityService.listCAs() later you might want to use DataCollection because it provides the fields to put the total results, the entries in the current page, and the paging links. -- Endi S. Dewata
On Fri, 2015-09-18 at 05:59 -0500, Endi Sukma Dewata wrote:
On 9/14/2015 2:25 AM, Fraser Tweedale wrote:
The latest lightweight CAs (f.k.a. Sub-CAs) patches are attached. This cut has significant changes and additions including:
- CAs are now stored in a flat structure with references to parents
- CAs are now identified by "AuthorityID" (which for now is a UUID underneath). Many variables, method names and user-visible strings were updated accordingly. Out with "caRef" terminology.
- "Sub-CA" terminology is (mostly) out; "Authority" is in. This is to support lightweight CAs that are not descendents of top-level CA (which can be implemented later).
- ca-cert-request-submit command and related client / service classes were updated to add "authority" parameter
- Some more specific use of exception (including some new exception classes) to indicate / catch particular errors.
- More appropriate HTTP status codes return when client has send invalid data (400), referenced unknown authority (404) or attempts to create an authority with Subject DN already uesd by another authority (409 Conflict)
- LDAP entry now gets added before key generation and signing. If something goes wrong, the DB entry is removed in the catch block.
There are still notable gaps in functionality that are in progress or will be implemented soon:
- Audit log events - Resources to enable/disable/delete authority - Resources to access cert and pkcs7 chain of authority - Keygen params - Param to specify token on which to generate authority key
Thanks, Fraser
Some comments:
1. The db.ldif creates ou=subCAs instead of ou=authorities.
yup -Fraser already knows about this one.
2. Is authority DN globally unique? If that's the case it can be used as a user-friendly representation of the UUID. We'll continue to use UUID for the LDAP entry DN and REST URL, but users don't really need to see it in the CLI (except in detailed output). So the CLI output can be changed as follows: * Issuer DN/ID -> Authority DN * Parent ID -> Parent DN
I think "Issuer DN" is more appropriate to be used in the context of a certificate to refer to the authority that issued the certificate.
I think I've been living in the openstack world too long, but I have no objection to seeing UUIDs. In fact, you need to see the UUID in order to figure out what to put in for the authority ID when making a request. So, showing the ID is required.
3. Right now it's possible to create an authority with the same DN as the main CA's DN (it created the LDAP entry, but later failed due to nickname mismatch). If authority DN is unique, we shouldn't allow that.
agreed - we need to check for this.
We can fix this by creating the main authority LDAP entry during installation. It's not just for fixing this issue, but all authorities (including the top-level ones) should have the corresponding LDAP entries.
4. In CertificateAuthority.createCA() if no parent is specified, the authority will be added as a subordinate of the main CA. I think adding an authority without parent should be reserved for top-level authorities which we may support in the future. For now the ca-authority-create CLI should require a parent. In #3 we're adding the main CA entry, so there's always a parent.
thats a great idea. And yeah, we will eventually be considering multiple top-level authorities.
5. In the CLI output, if the authority doesn't have a Parent ID it shows a "null". It would be better to show "None" instead, or just don't show the Parent ID at all.
I like parent ids, but null is not user friendly.
6. Assuming authority DN is unique, we can add --issuer <DN> option to these commands: * pki ca-cert-find --issuer <dn> * pki ca-cert-request-submit --issuer <dn> * pki client-cert-find --issuer <dn> * pki client-cert-request --issuer <dn>
If we do this, then we need to be sure that the DN is normalized - both on input -- ie. when the subca is created (we need to do this in any case) and also on processing in the CLI. I'm ok with offering this as an option (maybe --issuer_dn), but the primary (and initially required option) will be using UUID. We can defer this mechanism to another ticket/patch. Please open one.
7. I think we should store authority DN and parent DN in the LDAP entry itself. This way we don't need to rely on the nickname and NSS database to figure out the DNs.
agreed.
8. Right now the authority certs & keys are stored in the NSS database. I'm not sure about the scalability & manageability (e.g. replication, orphaned keys). It might be OK for now, but if possible they should be stored (securely) in the LDAP entry itself or in KRA. We probably only need to store the certs & keys of the top-level authorities in the NSS database.
This was a big discussion a few months ago, and it was decided then that we were not comfortable with storing the keys in ldap. We can reconsider - but the mechanism of transferring keys is supposed to be custodia. 9. To support paging in AuthorityService.listCAs() later you might want
to use DataCollection because it provides the fields to put the total results, the entries in the current page, and the paging links.
agreed.
On 9/18/2015 1:46 PM, Ade Lee wrote:
6. Assuming authority DN is unique, we can add --issuer <DN> option tothese commands: * pki ca-cert-find --issuer <dn> * pki ca-cert-request-submit --issuer <dn> * pki client-cert-find --issuer <dn> * pki client-cert-request --issuer <dn>
If we do this, then we need to be sure that the DN is normalized - both on input -- ie. when the subca is created (we need to do this in any case) and also on processing in the CLI.
I'm ok with offering this as an option (maybe --issuer_dn), but the primary (and initially required option) will be using UUID. We can defer this mechanism to another ticket/patch. Please open one.
Per IRC discussion we agreed with these options: * --issuer-id <ID> * --issuer-dn <DN> to be added to the ca-cert-* and client-cert-request commands. For the client-cert-find command we can only provide this option: * --issuer-dn <DN> since issuer ID is irrelevant on the client. Personally I think the issuer DN would be more useful since that's the value that you see in certificates, so it's more consistent everywhere, and no need to do a lookup to find the issuer ID. Also, although most likely we will copy & paste the ID or DN anyway, the DN is easier to read and confirm that you're submitting the request to the right authority. -- Endi S. Dewata
Updated patches attached. I have addressed all items from the most recent review** and from my IRC conversations with Ade on Wednesday. ** not all items from earlier reviews addressed yet The subject and issuer DNs are now stored in LDAP but I have not yet refactored the lightweight CA loading code to read them instead of reading the DN from the cert in in the NSSDB. This will be fixed of necessity when implementing replication support. Also note that patches 0048..0050 which appeared earlier have been squashed down into 0026 and 0044. Thanks, Fraser
Latest patches attached. Relative to previous patchset this one: - fixes a compile error in CATest.java - fixes a ton of warnings and some poorly ordered imports - adds ACLs and ACL enforcement for privileged operations on AuthorityResource Here's an ldif snippet for adding the ACLs to an existing database dn: cn=aclResources,o=ipaca changetype: modify add: resourceACLS resourceACLS: certServer.ca.authorities:list,read:allow (list,read) user="anybody":Anybody may list and read lightweight authorities resourceACLS: certServer.ca.authorities:create,modify:allow (create,modify) group="Administrators":Administrators may create and modify lightweight authorities Cheers, Fraser On Fri, Sep 18, 2015 at 02:11:27PM -0500, Endi Sukma Dewata wrote:
On 9/18/2015 1:46 PM, Ade Lee wrote:
6. Assuming authority DN is unique, we can add --issuer <DN> option tothese commands: * pki ca-cert-find --issuer <dn> * pki ca-cert-request-submit --issuer <dn> * pki client-cert-find --issuer <dn> * pki client-cert-request --issuer <dn>
If we do this, then we need to be sure that the DN is normalized - both on input -- ie. when the subca is created (we need to do this in any case) and also on processing in the CLI.
I'm ok with offering this as an option (maybe --issuer_dn), but the primary (and initially required option) will be using UUID. We can defer this mechanism to another ticket/patch. Please open one.
Per IRC discussion we agreed with these options: * --issuer-id <ID> * --issuer-dn <DN> to be added to the ca-cert-* and client-cert-request commands.
For the client-cert-find command we can only provide this option: * --issuer-dn <DN> since issuer ID is irrelevant on the client.
Personally I think the issuer DN would be more useful since that's the value that you see in certificates, so it's more consistent everywhere, and no need to do a lookup to find the issuer ID. Also, although most likely we will copy & paste the ID or DN anyway, the DN is easier to read and confirm that you're submitting the request to the right authority.
-- Endi S. Dewata
On 9/24/2015 9:20 AM, Fraser Tweedale wrote:
Latest patches attached. Relative to previous patchset this one:
- fixes a compile error in CATest.java - fixes a ton of warnings and some poorly ordered imports - adds ACLs and ACL enforcement for privileged operations on AuthorityResource
Here's an ldif snippet for adding the ACLs to an existing database
dn: cn=aclResources,o=ipaca changetype: modify add: resourceACLS resourceACLS: certServer.ca.authorities:list,read:allow (list,read) user="anybody":Anybody may list and read lightweight authorities resourceACLS: certServer.ca.authorities:create,modify:allow (create,modify) group="Administrators":Administrators may create and modify lightweight authorities
Cheers, Fraser
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. 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. 3. Per discussion with alee, we need a way to find the host/main CA using something like: $ pki ca-authority-show --host-authority 4. I think we also need a way to translate a DN into ID: $ pki ca-authority-show --dn <DN> 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. 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. 7. The method description in ISigningUnit.java doesn't match the method name (public vs. private). 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. -- Endi S. Dewata
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
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. 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!
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!
On Sat, Sep 26, 2015 at 12:30:02PM +1000, Fraser Tweedale wrote:
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.
Pushed to master: 058f1cf Lightweight CAs: REST cert request param to specify authority 5cdad30 Lightweight CAs: add ca-authority CLI 2a9f56d Lightweight CAs: initial support Cheers, Fraser
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!
_______________________________________________ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
On Fri, Sep 25, 2015 at 11:30:12PM +1000, Fraser Tweedale wrote:
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.
The observed NSS behaviour (one nickname for all certs with a given Subject DN) is by design. It was a limitation in the old nssdb design, but is now an artifical restriction to maintain the old behaviour. There is apparently no intention / desire to remove it. I will push forward with the subject+issuer patch, at least to get a working proof of concept and assess how it impacts the renewal process. Cheers, Fraser
participants (3)
-
Ade Lee -
Endi Sukma Dewata -
Fraser Tweedale