DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error
by Frederic d'Huart
Hello Pki users,
Section B.1.4. of the RH admin guide refers to the following acceptable
values
for crlDistributionPoint Type:
DirectoryName
URIName
RelativeToIssuer
Using PKIConsole, I have added to the caUserCert profile a policy for
include a CDP as follow:
policyset.userCertSet.13.default.name=CRL Distribution Points Extension
Default
policyset.userCertSet.13.default.params.crlDistPointsCritical=false
policyset.userCertSet.13.default.params.crlDistPointsEnable_0=true
policyset.userCertSet.13.default.params.crlDistPointsPointType_0=URIName
policyset.userCertSet.13.default.params.crlDistPointsPointName_0=http://xxx.xxx.xxx/crl/xxx.crl
policyset.userCertSet.13.default.params.crlDistPointsReasons_0=
after profile re-activated, and new request generated, I get the
following error on the agent interface:
The Certificate System has encountered an unrecoverable error.
Error Message:
/java.lang.ClassCastException: netscape.security.x509.Extension cannot
be cast to netscape.security.x509.CRLDistributionPointsExtension/
Please contact your local administrator for assistance.
Any Ideas what could be wrong ?
Thank you.
13 years, 2 months
Migration documentation
by Mike Mercier
Hello,
I have a dogtag-1.1.0 with fedora-ds-base-1.2.0 installed on Fedora
10. I would like to migrate this system to CentOS 5.5 using the
latest EPEL distribution without losing any data. Is there any
documentation available to accomplish this?
A bit of background:
2 servers with the following:
fedora-ds installed with replication between the two (using
certificates generated from dogtag)
self-signed CA on dogtag
dogtag installed on both with the second install joined to the
security domain of the first
If more details are required, please let me know.
Thanks,
Mike
13 years, 2 months
TPS with sub CA or with root CA?
by Fabian Bertholm
Hi,
When running multiple sub CAs with one common root CA.
Do I attach one TPS to the Root CA or do I attach multiple TPS systems
to each Sub CA?
Best regards,
fabe
13 years, 2 months
anyone had a challenge getting crts to publish to the file system?
by Dave Augustus
I have a brand new install on Centos 5.5 64.
I can't get it to publish certs to the file system, only LDAP. In
pkiconsole, when I first access the Publishing area, I get an error
message about not being authorized. I am using the CA admin account to
do this.
Any ideas?
Thanks,
Dave
13 years, 2 months
Re: [Pki-users] Best High Availability Design
by Dave Augustus
Hi Erwin,
I appreciate your response.
The primary reason for wanting to a PKI was to alleviate all the
self-signed certs that we are/will be using. Then I realized that it
could be expanded to include user authentication to our NOC web sites.
So this is how it has evolved.
Currently, I have a primary CA with a secondary CA.
* The primary CA is all hosted on a single host, host A, including
LDAP storage.
* The secondary CA is all hosted on a single host, host B, including
LDAP storage.
* The 2 LDAP servers are in a multi-master config with replication
agreements for the User database, not the CAs though.
* I will create all the certs from the secondary CA.
* We will create user certs
* We will create server certs
* Both hosts are in a 2-node corosync cluster.
So we have numerous single points of failure in this setup, hence my
questions. With I think of HA for this project, I think more along the
lines of availability and less about performance. I have 2 physical
hosts to work with, along with fibre channel with an OCFS2 volume
available to both hosts.
So I would think that what I am looking for is that all services could
be running on a single host, in case the other host failed. Dogtags
supports cloning and so for each service that I need (CA1,CA2, OCSP ), I
can use cloning with manual assistance. I just designate one of host A
or B to be the primary host for a given service. Them clone them to the
other host.
Thanks,
Dave
On 02/17/2011 11:42 AM, Erwin Himawan wrote:
> Hi Dave,
>
> Since PKI is so much flexible, your PKI architecture would be
> influenced by many factors such as number of subscribers, the
> diversity of your subscribers PKI needs, real time access, initial and
> operating cost, etc. Also, when you mentioned "HA", what kind of "HA"
> it is; e.g. HA for obtaining new cert, renewal cert, obtaining the
> latest revocation status information? HA for certificate publication
> in the repository? HA for CA access to the repository? What is the
> requirement in your PKI CP?
>
> Not knowing these factors are, it would be very difficult to come up
> with the "best" "HA" design for your circumstances.
>
> Regards,
> Erwin
>
>
> On Wed, Feb 16, 2011 at 10:15 PM, Dave Augustus
> <davea(a)ingraftedsoftware.com <mailto:davea@ingraftedsoftware.com>> wrote:
>
> We are in the planning stages of deploying a CA using dogtags.
> Here is what we know we need and what resources we have to work
> with. Any suggestions are welcome!
>
> A primary CA - only used to create the subordinate CAs.
> A subordinate CA - this would actually create the certs.
>
> We have 2 servers with shared fiber channel storage. Each
> currently has LDAP (389 project) installed and are replicating
> between themselves. The LDAP servers run on their own IPs. Also,
> these 2 servers are a corosync cluster with 4 resource groups:
> puppet, mysql, apache, snmptrapd and syslog-ng. Each of these have
> their own IP as well. None of these services are load-balanced.
> They are either on one or the other servers- all the files these
> services need are supported with fibre channel storage.
>
> Now the CA. Here is what I have considered:
> 1) CA1 runs on server1- it uses the local LDAP server for storage
> 2) CA2 runs on server2- it uses the local LDAP server for storage
> 3) A clone of CA1 runs on server2 using server2's LDAP storage
> 4) A clone of CA2 runs on server1 using server1's LDAP storage
>
> Ideally, we would run the service like we do apache. It would run
> on either host, but only one a time. It would have its files on
> shared storage to support this. The problem with this setup is the
> LDAP storage is the single point of failure as I cannot refer to 2
> LDAP servers at the same time, afaik.
>
> For HA, it seems that the best I could do would be to have both
> LDAP servers and all 4 PKI instances installed on shared storage.
>
> Any thoughts on this are greatly appreciated.
>
> Thanks,
> Dave
>
>
>
> _______________________________________________
> Pki-users mailing list
> Pki-users(a)redhat.com <mailto:Pki-users@redhat.com>
> https://www.redhat.com/mailman/listinfo/pki-users
>
>
13 years, 2 months
Security Officer Mode enabling - where does the ldap auth come from?
by Fabian Bertholm
Hi,
Im a little bit stuck on enabling the Security Officer Mode, I'm
following the guide at:
http://docs.redhat.com/docs/en-US/Red_Hat_Certificate_System/8.0/html/Man...
When formating the blank token my TPS likes to have authentication by
default on soKey format operations. This does not work, the
tps-debug.log says RA_Processor::RequestExtendedLogin - No Extended
Login Response Msg Received and aborts. I wonder where the login data
should come from as the ESC is not prompting for a ldap user/pw in
this case.
btw. I did not use the absolut path
/var/lib/pki-tps/cgi-bin/so/index.cgi as stated in guide but the http
url as this made more sendse to me.
When disabling the authentication for soKey format within the CS.cfg
then the formating runs through until the error:
RA:tdb_update - failed to add tokendb entry
RA_Format_Processor::Process - Failed to update the token database
I sniffed with wireshatk and I can see that the ldap addRequest to the
tokendb is failing with a syntax error: tokenUserID: value #0 invalid
per syntax. And indeed it is missing in the addRequest. I think this
is because the auth is disabled and now there is no UserID.
How to continue?
Best regards,
fabe
13 years, 2 months
Best High Availability Design
by Dave Augustus
We are in the planning stages of deploying a CA using dogtags. Here is
what we know we need and what resources we have to work with. Any
suggestions are welcome!
A primary CA - only used to create the subordinate CAs.
A subordinate CA - this would actually create the certs.
We have 2 servers with shared fiber channel storage. Each currently has
LDAP (389 project) installed and are replicating between themselves. The
LDAP servers run on their own IPs. Also, these 2 servers are a corosync
cluster with 4 resource groups: puppet, mysql, apache, snmptrapd and
syslog-ng. Each of these have their own IP as well. None of these
services are load-balanced. They are either on one or the other servers-
all the files these services need are supported with fibre channel storage.
Now the CA. Here is what I have considered:
1) CA1 runs on server1- it uses the local LDAP server for storage
2) CA2 runs on server2- it uses the local LDAP server for storage
3) A clone of CA1 runs on server2 using server2's LDAP storage
4) A clone of CA2 runs on server1 using server1's LDAP storage
Ideally, we would run the service like we do apache. It would run on
either host, but only one a time. It would have its files on shared
storage to support this. The problem with this setup is the LDAP storage
is the single point of failure as I cannot refer to 2 LDAP servers at
the same time, afaik.
For HA, it seems that the best I could do would be to have both LDAP
servers and all 4 PKI instances installed on shared storage.
Any thoughts on this are greatly appreciated.
Thanks,
Dave
13 years, 2 months
Exporting Keys from a Software Database
by Dave Augustus
Hello All,
Section 6.2 of the Install Guide discusses "Exporting Keys from a
Software Database". The command to do this is:
PKCS12Export -debug -d /var/lib/subsystem_name/alias -w p12pwd.txt -p
internal.txt -o master.p12
The manual never specifies "what" p12pwd.txt should contain. Same for
"internal.txt".
Of course, I know that these are passwords used during the installation
process...
But which ones?
Thanks,
Dave
13 years, 2 months
