Proposed API v 0.3
by Ade Lee
Hi all,
Removed some interfaces that will not be used as per Jack's mention.
Also added some controller objects to handle TKS operations (courtesy of
Jack)
And added some flows on page 2, so that we can see how the new interface
would all work together. I took a quick stab at the key archival/
recovery scenarios - but that probably needs more massaging from more
experienced PKI folks.
Adam, please wikify.
Ade
12 years, 5 months
the state of client auth and the new proposed restful interface
by Ade Lee
Hi all,
Client cert authentication is central to how the CS manages access to
its servlets. How we use and have used client auth is tricky though -
and has implications for the new and current interfaces.
In this email, I hope to lay out the current state of client-auth - what
works, what doesn't, and some thoughts as to how this affects the
currently proposed interface. More thoughts on how to solve some of the
problems would be really helpful.
We use client auth in the following ways:
I. There are servlets which never require client auth (ee pages mostly)
and some admin (mostly installation related) pages
II. There are servlets which always require client auth (agent pages)
III. There are servlets which may require client auth (admin pages from
the console) which can be configured to require client auth.
IV. Enrollment profiles (executed from the EE pages - which do not
require client auth) - which, when executed - require client auth to be
processed. Another example of this would be self-renewals. This is a
case where we start off in a non-clientauth context and switch to client
auth.
Here is a brief history of how we have implemented client auth to
satisfy the above cases:
1. Shared Port Configuration: In the past, we did not have ports that
were specified as client-auth/ non-client auth. Instead, if a servlet
required client auth, we would ask tomcat for the javax.x509.certificate
attribute and - through tomcatjss and jss - it would renegotiate the
connection and get the relevant certificate. This handled cases I-IV.
2. Separated Ports: Recently we changed the configuration to a port
separated configuration. EE, admin and agent operations occurred on
separate ports, which were configured to either require (agent) or not
require (ee.,admin) client auth. For case III, if client auth were
required, we configured the admin port to "want" - which would
essentially ask for a cert and continue if one was not provided. For
case IV, we continued to rely on tomcat-initiated renegotiation.
3. Separated ports with MITM fix: For older clients without the newer
renegotiation protocol that fixes MITM, renegotiation is disabled. This
means that case IV would fail for certain profiles and renewals. The
fix for this was to redirect the profile submission to a new client auth
required EE port.
4. CA behind an apache proxy. In this case, the outside world talks to
the CS through an httpd instance that talks to the CS though the ajp
port. This is the current configuration used in IPA.
* The decision as to whether a port is client auth/ non-client auth is
made in the proxy by mapping URLs. URLs that begin with /agent for
example require client auth. This handles cases I and II.
* III is more complicated but can be addressed in the same way. That is
we can tweak the URL matching rules to always permit the admin servlets
that always do not need client auth (like installation servlets), while
requiring client auth for other admin servlets.
* Case IV is currently broken. Tomcat still passes on the request for
the javax.x509.certificate attribute - but ajp does not understand this
request and drops it on the floor - resulting in a 5XX type error being
returned. As of now, I have been unable to find a way to configure ajp
to pass the request on to apache to have it renegotiate the connection.
5. The new proposed RESTful interface:
For Dogtag 9+, we have been envisioning that the CS instances would use
default ports and that they would still communicate with the outside
world through the http proxy.
At this point though, the new RESTful interface does not have any
indication as to whether the operation is agent/ee/admin -- no
indication of this in the URL -- so it is impossible to filter at the
httpd proxy based on URL. Moreover, case IV is still broken.
There is also an additional consideration - which for reference, I cam
going to call case V. Some operations which currently have different
output depending on whether they are executed as an agent or an ee user
- are mapped to the same servlet in the new proposed api.
An example is :
/pki/profiles -which would return a list of profiles
This is a different list depending on whether it is executed as an agent
or whether it is executed as an EE user.
Possible Solutions (so far):
1. Whether we use client auth is closely tied to our conception of who
is executing the command. We have defined roles : ee, agent, admin in
the CS. Perhaps we should add these to the proposed URI pattern?
So we might have /pki/agent/certificates and /pki/ee/certifcates etc.
This would allow URL filtering on the proxy along the same lines as now
- solving cases I,II,III and V. Case IV is still broken.
2. Another solution might be to - once we have determined that a client
cert is required (and has not been provided) - send a temporary redirect
to say /pki/getClientCert - with a 307 (temporary redirect) code. This
servlet could be configured in the proxy to require client auth.
This would presumably be the equivalent of renegotiating the connection
- except using apache rather than tomcat to do it. And it would solve
all five cases listed above.
3, If we can figure out how to get ajp to pass back a request to
renegotiate the connection, then this might be the best solution yet.
Then we do not need to change any CS code - when we determine that we
need a client cert - it will be passed back to the proxy - and the proxy
will get the cert.
Ade
12 years, 5 months
Keytab for talking to PKI CA from IPA
by Adam Young
When setting up replication, it should not be necessary to cache any
passwords, anywhere, until the replication agreemsnts are set up, and
then, all caching should be using known secure mechanisms.
The two main repositories we care about are the Directory Server
instances managed by IPA and the Certificate Authority. Currently,
these are not in the same Dir Srv isntance (although they could be) due
to the fact that we expect to replicate them seperately. Specifically,
we expect to have more IPA instances than CA instances, and we will not
have a CA instance without a co-located IPA instance.
During normal operations, the IPA instance should not need to talk to
the directory server instance of the CA. All communication between IPA
and the CA should happen via the HTTPS secured via Certificates issued
by the CA.
Once the replication process starts, the file generated by ipa-prepare
replicate should not need an passwords. Instead, when the replicated
server is installed, the user performing the install should get a ticket
as an administrative user. All authentication for the replication
should be based on that ticket.
The very first step is to install an new Directory server for IPA. For
this, the replication process can generate a single use password and use
it as the Directory server password for the local instance. Next, the
ticket for the adminiustrative user should be used to download a keytab
for the Directory Server to use when communicating back to the original
IPA directory server.With these keytab in place, the replicated IPA DS
should be able to talk to the original IPA DS and establish the
replication agreement. At this point, the single use password should be
disabled.
Once the IPA Directory server has been replicated, we can either use the
original keytab or download a second keytab to establish a replication
agreement between the replicated CA directory server and the original CA
directory server. The process would look the same as setting up the
keytab for the IPA directory server.
Why don't we do this now?
12 years, 5 months
Keytab for talking to PKI CA from IPA
by Adam Young
When setting up replication, it should not be necessary to cache any
passwords, anywhere, until the replication agreemsnts are set up, and
then, all caching should be using known secure mechanisms.
The two main repositories we care about are the Directory Server
instances managed by IPA and the Certificate Authority. Currently,
these are not in the same Dir Srv isntance (although they could be) due
to the fact that we expect to replicate them seperately. Specifically,
we expect to have more IPA instances than CA instances, and we will not
have a CA instance without a co-located IPA instance.
During normal operations, the IPA instance should not need to talk to
the directory server instance of the CA. All communication between IPA
and the CA should happen via the HTTPS secured via Certificates issued
by the CA.
Once the replication process starts, the file generated by ipa-prepare
replicate should not need an passwords. Instead, when the replicated
server is installed, the user performing the install should get a ticket
as an administrative user. All authentication for the replication
should be based on that ticket.
The very first step is to install an new Directory server for IPA. For
this, the replication process can generate a single use password and use
it as the Directory server password for the local instance. Next, the
ticket for the adminiustrative user should be used to download a keytab
for the Directory Server to use when communicating back to the original
IPA directory server.With these keytab in place, the replicated IPA DS
should be able to talk to the original IPA DS and establish the
replication agreement. At this point, the single use password should be
disabled.
Once the IPA Directory server has been replicated, we can either use the
original keytab or download a second keytab to establish a replication
agreement between the replicated CA directory server and the original CA
directory server. The process would look the same as setting up the
keytab for the IPA directory server.
Why don't we do this now?
12 years, 5 months
What CA constraints?
by Rob Crittenden
Shanks was testing signing an IPA CA cert request with an external CA
and found an issue, see https://fedorahosted.org/freeipa/ticket/2019 for
full details.
In short the issue is the CA he did the signing with wasn't really a
full CA. It was lacking all sorts of constraints. I had him try again
using a proper CA and it worked fine.
We'd like to detect this at install time, I'm just not exactly sure what
the minimum requirements are. I also wonder if dogtag should be doing
this enforcement or if IPA should (or both, perhaps).
Where should we start?
rob
12 years, 6 months
Patch for review - Fix mod_revocator shutdown on 32-bit platforms . . .
by Matthew Harmsen
* *Bugzilla Bug #716355*
<https://bugzilla.redhat.com/show_bug.cgi?id=716355> -
mod_revocator does not shut down httpd server if expired CRL is
fetched
* *Bugzilla Bug #716361*
<https://bugzilla.redhat.com/show_bug.cgi?id=716361> -
mod_revocator does not bring down httpd server if CRLUpdate fails
Please review the attached patch (which should address both Bugzilla
Bugs listed above):
* https://bugzilla.redhat.com/attachment.cgi?id=529578&action=diff&context=...
TESTING THIS PATCH ON A 32-bit RHEL 5 SYSTEM:
# date
Fri Oct 21 15:50:26 PDT 2011
# cd /var/log/httpd
# /sbin/service httpd start
# tail -f error_log
[Fri Oct 21 16:58:40 2011] [notice] core dump file size limit raised to
4294967295 bytes
[Fri Oct 21 16:58:40 2011] [notice] SELinux policy enabled; httpd
running as context user_u:system_r:httpd_t
[Fri Oct 21 16:58:40 2011] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/suexec)
[Fri Oct 21 16:58:42 2011] [notice] Digest: generating secret for digest
authentication ...
[Fri Oct 21 16:58:42 2011] [notice] Digest: done
[Fri Oct 21 16:58:42 2011] [notice] mod_python: Creating 4 session
mutexes based on 256 max processes and 0 max threads.
[Fri Oct 21 16:58:43 2011] [notice] Apache/2.2.3 (Red Hat) configured --
resuming normal operations
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
# date -s "Fri Sep 21 15:50:26 PDT 2012"
Fri Sep 21 15:50:26 PDT 2012
# tail -f error_log
[Fri Oct 21 16:58:40 2011] [notice] core dump file size limit raised to
4294967295 bytes
[Fri Oct 21 16:58:40 2011] [notice] SELinux policy enabled; httpd
running as context user_u:system_r:httpd_t
[Fri Oct 21 16:58:40 2011] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/suexec)
[Fri Oct 21 16:58:42 2011] [notice] Digest: generating secret for digest
authentication ...
[Fri Oct 21 16:58:42 2011] [notice] Digest: done
[Fri Oct 21 16:58:42 2011] [notice] mod_python: Creating 4 session
mutexes based on 256 max processes and 0 max threads.
[Fri Oct 21 16:58:43 2011] [notice] Apache/2.2.3 (Red Hat) configured --
resuming normal operations
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Sep 21 15:50:28 2012] [error] CRL
http://meatpie.dsdev.sjc.redhat.com:9180/ca/ee/ca/getCRL?op=getCRL&crlIss...
CN=Certificate Authority,OU=pki-ca,O=DsdevSjcRedhat Domain is outdated.
Shutting down server pid 25012
[Fri Sep 21 15:50:29 2012] [notice] caught SIGTERM, shutting down
# /sbin/service httpd status
httpd dead but subsys locked
# /sbin/service httpd restart
Stopping httpd: [FAILED]
Starting httpd: [ OK ]
# tail -f error_log
[Fri Oct 21 16:58:40 2011] [notice] core dump file size limit raised to
4294967295 bytes
[Fri Oct 21 16:58:40 2011] [notice] SELinux policy enabled; httpd
running as context user_u:system_r:httpd_t
[Fri Oct 21 16:58:40 2011] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/suexec)
[Fri Oct 21 16:58:42 2011] [notice] Digest: generating secret for digest
authentication ...
[Fri Oct 21 16:58:42 2011] [notice] Digest: done
[Fri Oct 21 16:58:42 2011] [notice] mod_python: Creating 4 session
mutexes based on 256 max processes and 0 max threads.
[Fri Oct 21 16:58:43 2011] [notice] Apache/2.2.3 (Red Hat) configured --
resuming normal operations
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Sep 21 15:50:28 2012] [error] CRL
http://meatpie.dsdev.sjc.redhat.com:9180/ca/ee/ca/getCRL?op=getCRL&crlIss...
CN=Certificate Authority,OU=pki-ca,O=DsdevSjcRedhat Domain is outdated.
Shutting down server pid 25012
[Fri Sep 21 15:50:29 2012] [notice] caught SIGTERM, shutting down
[Fri Sep 21 15:54:30 2012] [notice] core dump file size limit raised to
4294967295 bytes
[Fri Sep 21 15:54:30 2012] [notice] SELinux policy enabled; httpd
running as context user_u:system_r:httpd_t
[Fri Sep 21 15:54:30 2012] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/suexec)
[Fri Sep 21 15:54:31 2012] [notice] Digest: generating secret for digest
authentication ...
[Fri Sep 21 15:54:31 2012] [notice] Digest: done
[Fri Sep 21 15:54:31 2012] [notice] mod_python: Creating 4 session
mutexes based on 256 max processes and 0 max threads.
[Fri Sep 21 15:54:32 2012] [notice] Apache/2.2.3 (Red Hat) configured --
resuming normal operations
[Fri Sep 21 15:54:35 2012] [error] CRL
http://meatpie.dsdev.sjc.redhat.com:9180/ca/ee/ca/getCRL?op=getCRL&crlIss...
CN=Certificate Authority,OU=pki-ca,O=DsdevSjcRedhat Domain is outdated.
Shutting down server pid 25059
[Fri Sep 21 15:54:39 2012] [warn] child process 25065 still did not
exit, sending a SIGTERM
[Fri Sep 21 15:54:41 2012] [warn] child process 25065 still did not
exit, sending a SIGTERM
[Fri Sep 21 15:54:43 2012] [warn] child process 25065 still did not
exit, sending a SIGTERM
[Fri Sep 21 15:54:45 2012] [error] child process 25065 still did not
exit, sending a SIGKILL
[Fri Sep 21 15:54:46 2012] [notice] caught SIGTERM, shutting down
# /sbin/service httpd status
httpd dead but subsys locked
# date -s "Fri Oct 21 15:50:26 PDT 2011"
Fri Oct 21 15:50:26 PDT 2011
# /sbin/service httpd restart
Stopping httpd: [FAILED]
Starting httpd: [ OK ]
# tail -f error_log
[Fri Oct 21 16:58:40 2011] [notice] core dump file size limit raised to
4294967295 bytes
[Fri Oct 21 16:58:40 2011] [notice] SELinux policy enabled; httpd
running as context user_u:system_r:httpd_t
[Fri Oct 21 16:58:40 2011] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/suexec)
[Fri Oct 21 16:58:42 2011] [notice] Digest: generating secret for digest
authentication ...
[Fri Oct 21 16:58:42 2011] [notice] Digest: done
[Fri Oct 21 16:58:42 2011] [notice] mod_python: Creating 4 session
mutexes based on 256 max processes and 0 max threads.
[Fri Oct 21 16:58:43 2011] [notice] Apache/2.2.3 (Red Hat) configured --
resuming normal operations
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 16:58:44 2011] [notice] Revocation subsystem initialized 2
[Fri Sep 21 15:50:28 2012] [error] CRL
http://meatpie.dsdev.sjc.redhat.com:9180/ca/ee/ca/getCRL?op=getCRL&crlIss...
CN=Certificate Authority,OU=pki-ca,O=DsdevSjcRedhat Domain is outdated.
Shutting down server pid 25012
[Fri Sep 21 15:50:29 2012] [notice] caught SIGTERM, shutting down
[Fri Sep 21 15:54:30 2012] [notice] core dump file size limit raised to
4294967295 bytes
[Fri Sep 21 15:54:30 2012] [notice] SELinux policy enabled; httpd
running as context user_u:system_r:httpd_t
[Fri Sep 21 15:54:30 2012] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/suexec)
[Fri Sep 21 15:54:31 2012] [notice] Digest: generating secret for digest
authentication ...
[Fri Sep 21 15:54:31 2012] [notice] Digest: done
[Fri Sep 21 15:54:31 2012] [notice] mod_python: Creating 4 session
mutexes based on 256 max processes and 0 max threads.
[Fri Sep 21 15:54:32 2012] [notice] Apache/2.2.3 (Red Hat) configured --
resuming normal operations
[Fri Sep 21 15:54:35 2012] [error] CRL
http://meatpie.dsdev.sjc.redhat.com:9180/ca/ee/ca/getCRL?op=getCRL&crlIss...
CN=Certificate Authority,OU=pki-ca,O=DsdevSjcRedhat Domain is outdated.
Shutting down server pid 25059
[Fri Sep 21 15:54:39 2012] [warn] child process 25065 still did not
exit, sending a SIGTERM
[Fri Sep 21 15:54:41 2012] [warn] child process 25065 still did not
exit, sending a SIGTERM
[Fri Sep 21 15:54:43 2012] [warn] child process 25065 still did not
exit, sending a SIGTERM
[Fri Sep 21 15:54:45 2012] [error] child process 25065 still did not
exit, sending a SIGKILL
[Fri Sep 21 15:54:46 2012] [notice] caught SIGTERM, shutting down
[Fri Oct 21 15:51:01 2011] [notice] core dump file size limit raised to
4294967295 bytes
[Fri Oct 21 15:51:01 2011] [notice] SELinux policy enabled; httpd
running as context user_u:system_r:httpd_t
[Fri Oct 21 15:51:01 2011] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/suexec)
[Fri Oct 21 15:51:03 2011] [notice] Digest: generating secret for digest
authentication ...
[Fri Oct 21 15:51:03 2011] [notice] Digest: done
[Fri Oct 21 15:51:03 2011] [notice] mod_python: Creating 4 session
mutexes based on 256 max processes and 0 max threads.
[Fri Oct 21 15:51:04 2011] [notice] Apache/2.2.3 (Red Hat) configured --
resuming normal operations
[Fri Oct 21 15:51:06 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 15:51:06 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 15:51:06 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 15:51:06 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 15:51:06 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 15:51:06 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 15:51:06 2011] [notice] Revocation subsystem initialized 2
[Fri Oct 21 15:51:06 2011] [notice] Revocation subsystem initialized 2
NOTE: PATCH WAS ALSO TESTED ON A 64-BIT PLATFORM TO DETERMINE THAT NO
REGRESSION OCCURRED.
12 years, 6 months
latest restful interface doc
by Ade Lee
Based on discussions with jmagne and ayoung, here is the latest version.
Please feel free to comment!
ayoung will post to wiki.
Ade
12 years, 6 months