[PATCH] Stand-alone DRM (manual GUI configuration only)
by Matthew Harmsen
The following patch addresses the installation and configuration of a
stand-alone DRM (i. e. - a DRM that exists as the sole subsystem in a
PKI deployment -- no corresponding Dogtag CA, and no corresponding
Security Domain). Eventually, this DRM will be able to be installed and
configured (as a two step process) using nothing more than 'pkispawn'
and the REST interface (Phase II). As a preliminary step, this patch
allows a stand-alone DRM to be installed using 'pkispawn' and manually
configured using the GUI panel interface via a Firefox browser (Phase I).
Although this patch only addresses Phase I of a stand-alone DRM, the
patch does contain some additional code changes for Phase II, and
although incomplete at this time, none of these changes should conflict
with existing subsystems.
Finally, although this patch only addresses Phase I of configuring a
stand-alone DRM, I thought it prudent to send out the existing code
changes due to the relatively healthy size of this effort.
The attached patch addresses the following TRAC tickets:
* https://fedorahosted.org/pki/ticket/667 TRAC Ticket #667 - provide
option for ca-less drm install (Phase I)
* https://fedorahosted.org/pki/ticket/641 TRAC Ticket #641 - Incorrect
interface labels in pkidaemon output
* https://fedorahosted.org/pki/ticket/707 TRAC Ticket #707 -Do not
"require" the following pkispawn parameters for GUI-based configuration
The attached patch has been used to successfully install a Stand-alone
DRM using the manual GUI panels.
The DRM was installed using the following command:
* pkispawn -s KRA -f kra.cfg -vvv
where 'kra.cfg' contained the following:
* [DEFAULT]
pki_admin_password=XXXXXXXX
pki_client_pkcs12_password=XXXXXXXX
pki_skip_configuration=True
[KRA]
pki_standalone=True
The DRM was then manually configured from a Firefox browser using the
GUI panels where:
* this DRM is not part of any security domain,
* this DRM's transport, storage, sslserver, and audit_log_signing
certificates were all submitted and externally signed by a separate
pre-installed Dogtag CA using the appropriate profiles,
* a cert request for this DRM's Admin certificate was saved in its
CS.cfg to be used later
Although I have no tests to verify that this stand-alone DRM functions
correctly, the standalone DRM server can be successfully installed,
manually configured by the GUI panels, and started:
* pkidaemon status tomcat pki-tomcat
Status for pki-tomcat: pki-tomcat is running ..
[DRM Status Definitions]
Unsecure URL = http://dogtag19.example.com:8080/kra/ee/kra
Secure Agent URL =
https://dogtag19.example.com:8443/kra/agent/kra
Secure EE URL = https://dogtag19.example.com:8443/kra/ee/kra
Secure Admin URL =
https://dogtag19.example.com:8443/kra/services
PKI Console Command = pkiconsole
https://dogtag19.example.com:8443/kra
Tomcat Port = 8005 (for shutdown)
[DRM Configuration Definitions]
PKI Instance Name: pki-tomcat
PKI Subsystem Type: DRM (Stand-alone)
Please review this patch, so that Phase I of this effort may be checked-in.
11 years, 1 month
Re: [Pki-devel] [Freeipa-devel] [SSSD] FreeIPA on Debian
by Nathan Kinder
On 09/01/2013 01:35 PM, Timo Aaltonen wrote:
> On 01.09.2013 21:43, Dmitri Pal wrote:
>> On 09/01/2013 02:20 PM, Timo Aaltonen wrote:
>>> On 31.08.2013 00:04, Dmitri Pal wrote:
>>>> Hello,
>>>>
>>>> Sorry for cross posting to 4 different lists but it seems that this is
>>>> the best way to include most of people who might be interested in this
>>>> discussion.
>>>>
>>>> The question of "When FreeIPA will be available on Debian?" has been
>>>> coming up periodically on the list(s) without any resolution. However it
>>>> is clear that it would be beneficial for the community and the project.
>>> Hi,
>>>
>>> As you know, I've been packaging stuff for the past two years with the
>>> goal of eventually having FreeIPA server on Debian/Ubuntu. A lot has
>>> been accomplished, but quite a bit is still missing too..
>>>
>>>> May be it is time to try again?
>>>> Let us see why it yet has not happened?
>>>>
>>>> 1) Some components need to be ported to Debian especially Dogtag and a
>>>> slew of its new RESTEasy dependencies. This requires time and quite an
>>>> effort from someone familiar with the domain.
>>> Yes, this is the biggest blocker. Dogtag 9 is packaged in git and
>>> working, but I'm not going to push that to the distro. It can be used
>>> for testing the IPA server though, before we have Dogtag 10. Once the
>>> prereqs are in place the Dogtag git should be easy to rebase with 10.x.
>>>
>>> I did start packaging some of the dependencies, but hit a wall when some
>>> maven component needed a different release than another one.. AIUI this
>>> is a known issue with maven based projects..
I would like to organize the effort to get Dogtag 10 ported to Debian.
I know that there are a lot of dependencies needed for this to happen.
I can create and maintain a wiki page to track all of the work that is
needed to get this porting done. Do you have a list of Dogtag 10
dependencies that are not currently packaged for Debian that I can use
as a starting point? Once we have a clear outline of what is needed, we
can start trying to divide up and schedule the work.
Do you have more details on the maven issue you were running up against?
Thanks,
-NGK
>>>
>>> Other blockers off the top of my head include:
>>>
>>> - support for shared certificate database in NSS
>>> * patches sent to the Debian bug (#537866), maintainer isn't too
>>> responsive
>> How can we help?
> I don't think you can, guess it just needs some perseverance on my side..
>
>>> - dyndb support in bind
>>> * haven't asked the maintainer to add it to bind9, it might happen
>> Are you talking about byndb maintainer or bind9 Debian maintainer?
>> May be we should connect the two?
> the debian bind maintainer, I heard from the dyndb maintainer that
> bind10 might support it natively, but getting that in Debian might still
> be further in the future, so if we'd need dyndb by early next year it's
> probably needed to have it via bind9 first.
>
>>>> 3) Someone needs to own packages in Debian and maintain them, someone
>>>> with good knowledge of the distro and time to take ownership of about 50
>>>> packages.
>>> I'm doing this on my spare time, which has meant obvious delays in
>>> shipping something. Would be great to have more skillful people (pun
>>> intended) on the pkg-freeipa team..
>> Are you the only person there so far?
> pretty much, there have been some debian developers sponsoring packages
> to the distro (I'm not a DD yet), but they've all fled before too long :)
>
11 years, 1 month
[PATCH] 298 Added TPS connection resource.
by Endi Sukma Dewata
A skeleton for TPS connection services and the clients have been added.
The service implementation will be added later.
Ticket #652
--
Endi S. Dewata
11 years, 1 month
[PATCH] 297 Reorganized TPS classes.
by Endi Sukma Dewata
The TPS classes have been reorganized as follows:
* common: com.netscape.certsrv.tps
* CLI: com.netscape.cmstools.tps
* server: org.dogtagpki.server.tps
TPSConnection and TPSMessage were moved from server package into
common package. The build script and configuration files have been
modified accordingly.
--
Endi S. Dewata
11 years, 1 month
[PATCH] 147 - provide enrollment template per profile.
by Ade Lee
This patch adds an API call to the ProfileService interface to obtain an
enrollment template for a particular profile. The template is simply a
CertEnrollmentRequest with the relevant inputs for the profile filled
in. The user would then need to simply enter the relevant values and
submit the request using the REST API cert-request-submit.
I think that someone who is using this interface would do one of two
things:
1. Manually edit the template to generate the request.
2. Write client code to add the relevant data to the
CertEnrollmentRequest object.
In fact, I plan to submit a patch that will extend the pki CLI to allow
you to enter the data for a request interactively or through command
line arguments.
It would go something like this:
1. pki cert-request-submit --profile caCertUser
2. CLI will contact Profile service and get the relevant template which
is a CertEnrollmentRequest object.
3. CLI will then iterate through the attributes (which are all uniquely
named) and prompt for their value. The descriptor metadata can be used
to help generate the prompt.
4. CLI will take these results, populate the CertEnrollmentRequest and
send to server.
5. CLI can also take an invocation that looks like this perhaps:
pki cert-request-submit --profile caCertUser --profileArgs [--sn_e
alee(a)redhat.com --sn_cn "Ade Lee" ... ] so that you can do it all on the
command line.
Please review.
Ade
11 years, 1 month
[PATCH] 146 - Add audit logging to the Profile interface.
by Ade Lee
This patch adds audit logging to the profile interface. I used the same
logging categories (scope, op, id, messages) as for the old interface.
More needs to be added - in particular, when an input, output or policy
is added, modified or removed, the details of the attributes in that
object should probably be logged, rather than just the id's.
I'll fix this in a subsequent patch.
A comprehensive review of the audit logs will likely be done when we do
common criteria testing.
Please review.
Ade
11 years, 1 month
[PATCH] 150 fix for revocation reason
by Ade Lee
Fixed filter code for revocationReason
Filter was incorrectly setting ldap query to revocationReason*
resulting in a reach for revocationReason 1 returning 1 and 10
Ticket 712
Please review.
Ade
11 years, 1 month
