September 2013 - Pki-users - Dogtag PKI List Archives

Could RHCS81 run under RHEL59?
by 安泱 09 Oct '13

09 Oct '13

Hi all, service pki-ca start failed, in catalina.out: Caused by: java.security.AccessControlException: access denied (java.io.FilePermission /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/logging.properties read) The same installation method is OK under RHEL58, but could not run under RHEL59.

3 2

will the new version of RHCS support RHEL6?
by 安泱 07 Oct '13

07 Oct '13

Hi all, I'm a beginner of the dogtag certificate system, dogtag（RHCS）is a wonderful project, but I'm confused about RHCS, could you give any help? The latest version of RHCS is 8.1, which is based on dogtag 8.1, it supports RHEL5.8, and in RHEL6, pki-ca 9.0.3 was included without the other 5 subsystems, could you show me the consideration why RHCS do not support RHEL6? Is RHEL6 not secure enough or some other reasons？ Regards. An Yang

4 15

"Format" button never enabled in Enterprise Security Client
by Steve Ross 24 Sep '13

24 Sep '13

I'm a new user of the Dogtag Certificate System... I am trying to create a certificate and write it to a smart card. My problem is that my Enterprise Security Client (ESC) does not allow me to format the smart card. When I insert the blank smart card, the ESC GUI shows Issuer = Unknown Issued To = Unknown Status = Unformatted However, the "Format" button is disabled and remains so. Why? Is there any configuration that I need to do in one of the PKI subsystems or ESC itself? When I instead insert a Common Access Card (CAC), the ESC GUI shows Issuer = U.S Government Issued To = <name> Status = Enrolled and ESC is able to display thethree certificates of the CAC. So, my hardware/software is working to the extent that it can read another card. I see the section in the Red Hat Certificate System (RHCS) 8.1 "Deployment, Planning, and Installation" guide that says: The Certificate System subsystems have been tested using the following tokens: Gemalto TOP IM FIPS CY2 64K token, both as a smart card and GemPCKey USB form factor key Gemalto Cyberflex e-gate 32K token Safenet 330J Java smart card I also see the section of the RHCS "Managing Smart Cards with the Enterprise Security Client" that says: The Enterprise Security Client supports smart cards which are JavaCard 2.1 or higher and Global Platform 2.01-compliant and was tested using the following cards: Safenet 330J Java smart cards Gemalto 64K V2 tokens, both as a smart card and GemPCKey USB form factor key Gemalto GCx4 72K and TOPDLGX4 144K common access cards (CAC) Oberthur ID One V5.2 common access cards (CAC) Personal identity verification (PIV) cards, compliant with FIPS 201 The smart card that I'm using is none of the above, though it exceeds the standards that the ESC manual describes. Following are the details of my smart card, reader, and installed software: Smart card: J2A080 - NXP JAVA based smart card, 80k EEPROM This is supposed to meet the standards JCOP 2.4.1, JC 2.2.2, and GP 2.1.1. It is a new card and is not supposed to have any applets on it. Smart card reader: OmniKey 3121 Operating system: CentOS 5.9 Software packages installed: esc-1.1.0-14.el5.centos.1 pki-ca-1.3.6-1.el5 pki-tks-1.3.3-1.el5 pki-tps-1.3.1-1.el5 coolkey-1.1.0-15.el5 tomcat5-5.5.23-0jpp.40.el5_9 httpd-2.2.3-82.el5.centos Thanks in advance for any help, -- Steve Ross

2 4

Announcing the release of Dogtag 10.0.5
by Ade Lee 10 Sep '13

10 Sep '13

The Dogtag team is proud to announce the fifth errata build for Dogtag 10.0. Builds are available for Fedora 18 and Fedora 19 in the updates-testing repositories. Please try them out and provide karma to move them to the F18 and F19 stable repositories. Karma can be provided at https://admin.fedoraproject.org/updates for each package. == Build Versions == pki-core-10.0.5-1 pki-ra-10.0.5-1 pki-tps-10.0.5-1 dogtag-pki-10.0.5-1 dogtag-pki-theme-10.0.5-1 pki-console-10.0.5-1 == Highlights since Dogtag 10.0.4 == * Due to changes in systemd, restarting Dogtag 10 instances using systemctl restart pki-tomcatd.target failed. Changes have been made to the systemd startup configuration to ensure that this works correctly. In addition, configuration has been added to require systemd to accept an exit status of 143 (a correct exit status for the JVM) as valid, so this exit value will no longer be reported in the system logs. * Due to changes in the python-requests, a new exception (ProxyError) was returned when attempting to connect to a server that is not yet available. This affected pkispawn installation code when we wait for a server to restart. The code has been modified to handle this (and other) exceptions. * In a case following a bad restart, the CS.cfg for an instance appeared to be cleared or truncated. The code has been changed to not write server status to the CS.cfg on startup, but rather to use an in-memory variable. * Fixed LDAP search filter code to no longer return certificates expired for both reason 1 and reason 10 when searching only for reason 1. == Detailed Changes since Dogtag 10.0.4 == alee (5): #712 pki cert-find --revocationReason 1 finds certs expired for reason 1 and reason 10 #714 CS.cfg cleared #716 pki-tomcatd(a)pki-tomcat.service does not start when pki-tomcatd.target is started #717 Proxy error while getting status when spawning CA #719 Incorrect value in CS,cfg for manager.ldif location

1 0

Question about ETSI TS 102 231
by Jaime Hablutzel Egoavil 03 Sep '13

03 Sep '13

My question is the following one: *What is the meaning of http://uri.etsi.org/TrstSvc/eSigDir-1999-93-EC-TrustedList/SvcInfoExt/RootC… ETSI TS 102 231 V3.1.2 * >From Technical Spec http://uri.etsi.org/TrstSvc/eSigDir-1999-93-EC-TrustedList/SvcInfoExt/RootC… > a Root Certification Authority from which a certification path can be > established down to a Certification Authority issuing Qualified > Certificates. Only to be used as an extension, if the servicetype is > http://uri.etsi.org/TrstSvc/Svctype/CA/QC > But what is the purpose of having this URI associated to a TSPService > withServiceTypeIdentifier http://uri.etsi.org/TrstSvc/Svctype/CA/QC? Does it mean that if I have a prospective certificate path like this one: - A (root ca) - B (intermediate) - C (end user) Where A is the only one registered in the TSL as a TSPService without thehttp:// uri.etsi.org/TrstSvc/eSigDir-1999-93-EC-TrustedList/SvcInfoExt/RootCA-QCURI…, I can't construct a valid certification path for B and C? Is this the right place to make this kind of questions?? Or can you please recommend the right place to me please?? Is there something like a user mailing list or forum for ETSI Technical Specifications or IETF RFCs?? Thank you -- Jaime Hablutzel - RPC 994690880

1 0