Failing to install directory server on Fedora9-live USB-stick using the Data Persistence option.
by Ebbe Hansen
The "livecd-iso-to-disk" command appears to work OK when loading Fedora9
on-to a USB thumb-drive with "persistence" option (with an
appropriately sized overlay - I used 1 GBY overlay). Custom changes to
file-system and installation of new applications appears to survive
subsequent reboot sessions.
However, while attempting to install the DogTag system on the
"persistent" USB, I run unto trouble getting the Directory Server to
startup properly. The log-file indicates the configuration session went
OK - but the resulting instance does not start (or remain on running
state) - the log-file does not indicate any errors!
Have anyone on the list been successful getting the Directory Server
(and DogTag PKI) to install on a "persistent" live USB? I am using
fedora9 version 2.6.25-14.fc9.i686 - downloaded a few days ago. Any
comments & suggestions appreciated!
E. Hansen @ SPYRUS
15 years, 3 months
Help with Dogtag
by Stephen Hamilton
I just recently installed dogtag on my Fedora 9 system and I've gotten
nearly all of it working, except for one module that seems to crash the
http-worker process. After copying some jar's, editing a Modutil.pm to
remove a syntax error, I have singled this error down to one
thing--loading of the mod_tps.so in the pki-tps httpd.conf file. I can
comment this out and get TPS to work, but I get stuck on the security
modules page in the config wizard with it not finding any, or only
finding ones in the Other. The next button keeps me on this page.
Any help would be appreciated. Also, any ideas on how to load a cert
onto an Axalto 64kv2 card without loading dogtag would be just as
helpful--I feel like I'm reinventing the wheel just trying to get some
certs on a new card. I've gotten an old muscle applet loaded on the
card, and most recently have the coolkey applet loaded, and ESC is
recognizing it as a new card, hence why I'm loading dogtag to register
it.
Thanks in advance.
Stephen
15 years, 3 months
Help with the dogtag certificate system
by Nacho
Hi all.My name is Nacho.I'm trying to install the dogtag certificate system
on fedora 8. All packages have been installed perfectly but when I try to
run the CA, the following error occurs:
May 28, 2008 8:16:45 AM org.apache.catalina.core.ApplicationContext log
SEVERE: Servlet castart threw unload() exception
javax.servlet.ServletException: Servlet.destroy() for servlet castart threw
exception
at
org.apache.catalina.core.StandardWrapper.unload(StandardWrapper.java:1373)
at
org.apache.catalina.core.StandardWrapper.stop(StandardWrapper.java:1688)
at
org.apache.catalina.core.StandardContext.stop(StandardContext.java:4350)
at
org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:893)
at
org.apache.catalina.startup.HostConfig.undeployApps(HostConfig.java:1191)
at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1162)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:313)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
at
org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1055)
at
org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1067)
at
org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:448)
at
org.apache.catalina.core.StandardService.stop(StandardService.java:510)
at
org.apache.catalina.core.StandardServer.stop(StandardServer.java:734)
at org.apache.catalina.startup.Catalina.stop(Catalina.java:602)
at org.apache.catalina.startup.Catalina.start(Catalina.java:577)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:623)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
I took this error from the file "catalina.out" of the CA because the browser
was closed instantly
Does anyone have any idea how to fix it?
Thank you very much!
15 years, 3 months
Re: [Pki-users] Help with the dogtag certificate system
by Aleksander Adamowski
Nacho wrote:
>
> CMS Warning: FAILURE: Cannot build CA chain. Error
> java.security.cert.CertificateException: Certificate is not a PKCS #11 cer
> tificate|FAILURE: authz instance DirAclAuthz initialization failed and
> skipped, error=Property internaldb.ldapconn.port missi
> ng value|
I think this last line give us a hint. It seems that
internaldb.ldapconn.port is not set - it controls the port for internal
LDAP connection.
What port is your LDAP that holds CMS's internal database listening on?
I have my LDAP server listening on localhost on port 389, so in
/etc/pki-ca/CS.cfg I have:
authz.instance.DirAclAuthz.ldap.ldapconn.port=389
....
internaldb.ldapconn.port=389
Make sure all the .*ldapconn.* settings are correctly set and then
restart pki-ca.
In case of further problems, analyze /var/log/pki-ca/debug first,
because catalina.out only contains servlet container's errors and
servlet container is quite unlikely to malfunction (its role is quite
simple here).
--
Best Regards,
Aleksander Adamowski
GG#: 274614
ICQ UIN: 19780575
http://olo.org.pl
15 years, 3 months
Tomcat version information disclosure in default dogtag installation
by Aleksander Adamowski
Hi!
I've noticed that it's trivial to discover the exact version information
about the servlet container that runs a particular CA instance, one only
has to visit an invalid URL for a given instance, e.g.:
https://CA_SERVER:9443/qwerty
===================
HTTP Status 404 - /qwerty
type Status report
message /qwerty
description The requested resource (/qwerty) is not available.
Apache Tomcat/5.5.26
===================
Security by obscurity arguments aside, IMHO it's not so wise to
immediately provide exact version information for the server running
such security critical service. This information isn't a vulnerability
in itself, but makes it so much easier to plan an attack strategy for a
potential intruder.
In Apache, it's enough to use the "ServerTokens" configuration directive
to suppress giving out the exact server version, but AFAIK in Tomcat one
has to prepare a customised error page and configure it in web app's
web.xml (the <error-page> element -
http://www.apache-korea.org/tomcat/faq/misc.html#error).
With Tomact, most admins won't bother since it requires so much labour.
I think it would be nice to package simple error pages that don't
divulge version information in the pki RPMs by default - do you agree?
That would require modifying the following (all webapps' contexts have
to be customised):
/usr/share/pki/INSTANCE_NAME/conf/web.xml
/usr/share/pki/INSTANCE_NAME/webapps/ROOT/WEB-INF/web.xml
/usr/share/pki/INSTANCE_NAME/webapps/INSTANCE_NAME/WEB-INF/web.xml
--
Best Regards,
Aleksander Adamowski
GG#: 274614
ICQ UIN: 19780575
http://olo.org.pl
15 years, 4 months
SELinux policy for dogtag?
by Aleksander Adamowski
Hi!
Did anyone try to have a shot at creating a SELinux policy for dogtag
certificate system?
--
Best Regards,
Aleksander Adamowski
GG#: 274614
ICQ UIN: 19780575
http://olo.org.pl
15 years, 4 months
Does AuthTokenSubjectNameDefault plugin derive SubjectName incorrectly?
by Aleksander Adamowski
Hi!
I've noticed that with out LDAP directory, using the caDirUserCert
profile, we get incorrect SubjectNames - they aren't populated with
requesting users' commonName (cn) or e-mail (LDAP "mail" -> x.509 "E").
After closer inspection and brief analysis of Dogtag Certificate
System's source code I've identified that the
authTokenSubjectNameDefaultImpl plugin is responsible for this task and
its implementation is in the AuthTokenSubjectNameDefault class
(https://pki.fedoraproject.org/svn/pki/trunk/pki/base/common/src/com/netsc...).
The problem seems to be in this code fragment (line 134):
X500Name name = new X500Name(
request.getExtDataInString(IProfileAuthenticator.AUTHENTICATED_NAME));
The plug-in uses the $request.authenticatedname$ value from the request,
which contains the authenticated user's DN. If the DN doesn't contain
the cn and mail attribute, those attributed won't be propagated to
resulting certificate's subject name.
I think this plugin should use the $request.auth_token.tokencertsubject$
value.
After all, the UidPwdDiraAuth plugin's documentation
(http://www.redhat.com/docs/manuals/cert-system/pdf/cms601plugin.pdf)
implies that this value will be used to formulate the certificate's
subject name:
"dnpattern: Specifies a string representing a subject name pattern
to formulate from the
directory attributes and entry DN."
So the code should probably be change to something like this:
Index: src/com/netscape/cms/profile/def/AuthTokenSubjectNameDefault.java
===================================================================
--- src/com/netscape/cms/profile/def/AuthTokenSubjectNameDefault.java
(revision 47)
+++ src/com/netscape/cms/profile/def/AuthTokenSubjectNameDefault.java
(working copy)
@@ -131,7 +131,7 @@
// to the certinfo
try {
X500Name name = new X500Name(
-
request.getExtDataInString(IProfileAuthenticator.AUTHENTICATED_NAME));
+
request.getExtDataInAuthToken(AuthToken.TOKEN_CERT_SUBJECT));
info.set(X509CertInfo.SUBJECT, new
CertificateSubjectName(name));
} catch (Exception e) {
(note: I didn't test whether it works, I'd have to check out the whole
>130MB SVN repository and set up the complex Dogtag build
infrastructure for this...)
What you think?
--
Best Regards,
Aleksander Adamowski
GG#: 274614
ICQ UIN: 19780575
http://olo.org.pl
15 years, 4 months
Anybody got dual kay certs and key archiving working with Dogtag?
by Aleksander Adamowski
Hi!
I've set up pki-ca, pki-ocsp, pki-ra and pki-kra.
However, it seems that pki-kra doesn't archive any keys.
I've tested it with the following profiles when issuing certificates:
Using the CA instance:
* caUserCert (Manual User Dual-Use Certificate Enrollment) - I know, it
won't work, it's Dual-Use, not Dual-Key. However, the protocol used is CRMF.
* caDirUserCert (Directory-Authenticated User Dual-Use Certificate
Enrollment) - another Dual-Use, not Dual-Key. But CRMF-based.
* caDualRAuserCert (RA Agent-Authenticated User Certificate Enrollment)
- they don't write what "Dual" means here. Is it Dual-Use too?
Using the RA instance:
* caDualRAuserCert (RA Agent-Authenticated User Certificate Enrollment)
- it has "Dual" in its name...
So it seems that there's potential confusion over which "Dual" is
implied in the profile names (does it correspond to key usage, or the
amount of keys?).
Based on my experiments, either all those profiles are single key, or my
client doesn't support dual key generation (it's Firefox 3 nightly build).
So the question is - what combination of certificate profiles and client
(web browser) versions allows for generating dual key certificates whose
keys will be correctly archived by KRA/DRM?
--
Best Regards,
Aleksander Adamowski
GG#: 274614
ICQ UIN: 19780575
http://olo.org.pl
--
Aleksander Adamowski
Administrator systemów korporacyjnych; Instruktor
Altkom Akademia S.A. http://www.altkom.pl
Warszawa, ul. Chłodna 51
tel. brak
kom. +48 601-318-080
Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego Rejestru Sądowego,
KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN. Adres rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa.
Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę przedsiębiorstwa firmy Altkom Akademia S.A.
Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do własnych celów jest zabronione.
Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej wiadomości.
This message contains proprietary information and trade secrets of Altkom Akademia S.A. company.
Unauthorized use or disclosure of this information to any third party is prohibited.
If you received this message by mistake, please contact the sender immediately and delete all copies of this message.
15 years, 4 months
Modify Certificate Profies
by Chris
Sorry, hit the send by mistake....
I've succesfully installed Dogtag. The documentation was clear and I didn't
have any issues.
My question is in regards to customizing certificate profiles. In the
current CA environment I manager, I deal with customizing profiles. Is there
a way to create customized certificate profiles?
The fields which apply are:
CertificatePolicies
- Policy Identifier
- User Notice with custom text
ExtendedKeyUsage
- New Key Usage OID
Also, in one profile, we've created a new field that programically ties to
the EKU
On our current CA software, a config file is modified to customize profiles.
Also there is some DER encoding required to convert the appropriate text.
Is this feature available?
15 years, 4 months
