From shakthimaan at gmail.com Wed Aug 11 11:45:17 2010 From: shakthimaan at gmail.com (Shakthi Kannan) Date: Wed, 11 Aug 2010 17:15:17 +0530 Subject: [Pki-users] PKI subsystem webservice APIs Message-ID: Hi, Thanks for the Dogtag project. I have been able to install 389-ds and dogtag-pki-ca on Fedora 13. I am able to view the services through the browser. I would like to know if there are any web service APIs or tutorials or documents that are available to gives pointers on how to communicate with these server subsystems via other servers or programs? Appreciate any inputs in this regard, Thanks! SK -- Shakthi Kannan http://www.shakthimaan.com From mharmsen at redhat.com Thu Aug 12 03:49:32 2010 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 11 Aug 2010 20:49:32 -0700 Subject: [Pki-users] NOTICE: Dogtag Subversion Repositories have moved from 'pki.fedoraproject.org' to 'fedorahosted.org' Message-ID: <4C636F4C.105@redhat.com> Everyone, The Dogtag "pki" and "tomcatjss" subversion source repositories that were originally hosted on 'pki.fedoraproject.org' have been moved to 'fedorahosted.org'. The URLs referenced below provide check-out details for these new repositories: * http://pki.fedoraproject.org/wiki/PKI_Subversion_Instructions (pki) * http://pki.fedoraproject.org/wiki/PKI_Pre-Built_Support_Components (tomcatjss) STEP 1: Anyone working with these repositories will need to check out ALL of the brand "new" repos (notice the "new" syntax for these URLs): * svn co http://svn.fedorahosted.org/svn/pki/trunk/pki pki * svn co http://svn.fedorahosted.org/svn/tomcatjss/trunk/tomcatjss tomcatjss STEP 2: You will then need to "move" any changes from any "old" trees that you have to the "new" trees that you have created in STEP 1 above. Since the "old" repositories will be left running for the next week or two, it is recommended that you first perform an "svn update" on any "old" trees to iron out any conflicts prior to moving your changes to the "new" tree. For example: * cd tomcatjss; svn update * cd pki; svn update The Dogtag Wiki as well as the PKI and TOMCATJSS source tarballs will remain located at 'pki.fedoraproject.org'. Thanks, -- Matt NOTE: As a part of this migration, ALL Dogtag and tomcatjss packages have been increased from version 1.3 to 2.0 (in preparation of future planned changes to the Dogtag code base), so if you are building directly from subversion source (rather than using the Dogtag 1.3 SRPMS), then you may wish to use the following UNSUPPORTED BRANCH URLs instead: * svn co http://svn.fedorahosted.org/svn/pki/branches/DOGTAG_1_3_FREEIPA_v2_BRANCH/pki pki * svn co http://svn.fedorahosted.org/svn/tomcatjss/branches/DOGTAG_1_3_FREEIPA_v2_BRANCH/tomcatjss tomcatjss -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6654 bytes Desc: S/MIME Cryptographic Signature URL: From mharmsen at redhat.com Fri Aug 13 21:55:15 2010 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 13 Aug 2010 14:55:15 -0700 Subject: [Pki-users] NOTICE: Dogtag Subversion Repositories have moved from 'pki.fedoraproject.org' to 'fedorahosted.org' In-Reply-To: <4C636F4C.105@redhat.com> References: <4C636F4C.105@redhat.com> Message-ID: <4C65BF43.5080907@redhat.com> On 08/11/10 20:49, Matthew Harmsen wrote: > Everyone, > > The Dogtag "pki" and "tomcatjss" subversion source repositories that > were originally hosted on 'pki.fedoraproject.org' have been moved to > 'fedorahosted.org'. > > The URLs referenced below provide check-out details for these new > repositories: > > * http://pki.fedoraproject.org/wiki/PKI_Subversion_Instructions (pki) > * http://pki.fedoraproject.org/wiki/PKI_Pre-Built_Support_Components > (tomcatjss) > > STEP 1: Anyone working with these repositories will need to check out > ALL of the brand "new" repos (notice the "new" syntax for these URLs): > > * svn co http://svn.fedorahosted.org/svn/pki/trunk/pki pki > * svn co http://svn.fedorahosted.org/svn/tomcatjss/trunk/tomcatjss > tomcatjss > For users which have old trees, you will NOT need to "move" your changes, as a community member informed me about the an "svn switch --relocate" option. To sync your old trees with the new repository, merely perform the following steps: * cd pki * svn switch --relocate https://pki.fedoraproject.org/svn/pki http://svn.fedorahosted.org/svn/pki * svn update --- OR --- * cd tomcatjss * svn switch --relocate https://pki.fedoraproject.org/svn/fortitude http://svn.fedorahosted.org/svn/tomcatjss * svn update Remember to resolve any conflicts. I have documented this at http://pki.fedoraproject.org/wiki/PKI_Subversion_Instructions. Many thanks to Kaspar Brand! -- Matt > > STEP 2: You will then need to "move" any changes from any "old" trees > that you have to the "new" trees that you have created in STEP 1 > above. Since the "old" repositories will be left running for the next > week or two, it is recommended that you first perform an "svn update" > on any "old" trees to iron out any conflicts prior to moving your > changes to the "new" tree. For example: > > * cd tomcatjss; svn update > * cd pki; svn update > > The Dogtag Wiki as well as the PKI and TOMCATJSS source tarballs will > remain located at 'pki.fedoraproject.org'. > > Thanks, > -- Matt > > NOTE: As a part of this migration, ALL Dogtag and tomcatjss packages > have been increased from version 1.3 to 2.0 (in preparation of future > planned changes to the Dogtag code base), so if you are building > directly from subversion source (rather than using the Dogtag 1.3 > SRPMS), then you may wish to use the following UNSUPPORTED BRANCH URLs > instead: > > * svn co > http://svn.fedorahosted.org/svn/pki/branches/DOGTAG_1_3_FREEIPA_v2_BRANCH/pki > pki > * svn co > http://svn.fedorahosted.org/svn/tomcatjss/branches/DOGTAG_1_3_FREEIPA_v2_BRANCH/tomcatjss > tomcatjss > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6654 bytes Desc: S/MIME Cryptographic Signature URL: From gaiseric.vandal at gmail.com Tue Aug 31 18:43:02 2010 From: gaiseric.vandal at gmail.com (Gaiseric Vandal) Date: Tue, 31 Aug 2010 14:43:02 -0400 Subject: [Pki-users] DogTag 1.3 and Subject Alternate Name Message-ID: <4C7D4D36.3060005@gmail.com> I have installed DogTag 1.3 Certificate Server (CA and RA) components on Fedora Core 11. I want to configure a server certificate with a Subject Alternate Name. I used openssl to create a private key and a certificate signing request on the server in question. openssl genrsa -out server1.key -des3 1024 openssl req -new -key server1.key -out server.csr I am prompted along the way to include an e-mail address and subject alternate name. Both are permitted but optional in my openssl.cnf file. I can look at the csr with openssl req -in server.csr -text By default, openssl by default recreates a req with the following line Subject: C=US, ST=California, L=MyCity, O=MyCompany, OU=IT, CN=server.company.com/subjectAltName=www.company.com/emailAddress=mymail at company.com You can see that e-mail and SAN are part of the CN attribute. I went to the "Certificate System RA Services Page" (https://myserver:12890) - > SSL End Users Services -> Server Enrollment -> Request Submission. I pasted the contents of the csr file into the web page. The administrator (i.e. me) gets e-mail notification of a certificate request, and follows the link to approve it. However if I have included either e-mail or SAN the request will fail because the subject name doesn't match. CA: Request Rejected - Subject Name Not Matched E=mymail at company.com,CN=server.company.com,OU=IT,O=My Company,L=MyCity,ST=California,C=US If I compare the dogtag error message to the original csr file I can see that dogtag expects a different syntax for e-mail. Dogtag expects it as a separate "E" attribute (It still seems to have translated the attributes appropriately but then complains the subject doesn't match.) I can work around this by either omitting e-mail in the csr altogether or explicitly setting the subject attribute with the "openssl req -subj" -> openssl req -new -key server.key -out server.csr -subj "/E=mymail at company.com,CN=server.company.com,OU=IT,O=My Company Name,L=MyCity,ST=California,C=US" Enter pass phrase for server.key: Subject Attribute E has no known NID, skipped -> However, I can't figure out how to make this work for the Subject Alternate Name. DogTag rejects the certificate with CA: Request Rejected - Subject Name Not Matched E=mymail at company.com ,2.5.29.17=www.company.com,CN=server.... Is there a "NID" parameter than dogtag expects for SAN? -------------- next part -------------- An HTML attachment was scrubbed... URL: From msauton at redhat.com Tue Aug 31 19:13:04 2010 From: msauton at redhat.com (Marc Sauton) Date: Tue, 31 Aug 2010 12:13:04 -0700 Subject: [Pki-users] DogTag 1.3 and Subject Alternate Name In-Reply-To: <4C7D4D36.3060005@gmail.com> References: <4C7D4D36.3060005@gmail.com> Message-ID: <4C7D5440.90803@redhat.com> On 08/31/2010 11:43 AM, Gaiseric Vandal wrote: > > I have installed DogTag 1.3 Certificate Server (CA and RA) components > on Fedora Core 11. > > I want to configure a server certificate with a Subject Alternate Name. > > > I used openssl to create a private key and a certificate signing > request on the server in question. > > openssl genrsa -out server1.key -des3 1024 > openssl req -new -key server1.key -out server.csr > > > I am prompted along the way to include an e-mail address and subject > alternate name. Both are permitted but optional in my openssl.cnf file. > > I can look at the csr with > openssl req -in server.csr -text > > > > > By default, openssl by default recreates a req with the following line > > Subject: C=US, ST=California, L=MyCity, O=MyCompany, OU=IT, > CN=server.company.com/subjectAltName=www.company.com/emailAddress=mymail at company.com > > > > > You can see that e-mail and SAN are part of the CN attribute. > > I went to the "Certificate System RA Services Page" > (https://myserver:12890) - > SSL End Users Services -> Server > Enrollment -> Request Submission. I pasted the contents of the csr > file into the web page. The administrator (i.e. me) gets e-mail > notification of a certificate request, and follows the link to > approve it. However if I have included either e-mail or SAN the > request will fail because the subject name doesn't match. > > CA: Request Rejected - Subject Name Not Matched > E=mymail at company.com,CN=server.company.com,OU=IT,O=My > Company,L=MyCity,ST=California,C=US > > > > > If I compare the dogtag error message to the original csr file I can > see that dogtag expects a different syntax for e-mail. Dogtag > expects it as a separate "E" attribute (It still seems to have > translated the attributes appropriately but then complains the > subject doesn't match.) I can work around this by either omitting > e-mail in the csr altogether or explicitly setting the subject > attribute with the "openssl req -subj" > > -> openssl req -new -key server.key -out server.csr -subj > "/E=mymail at company.com,CN=server.company.com,OU=IT,O=My Company > Name,L=MyCity,ST=California,C=US" > Enter pass phrase for server.key: > Subject Attribute E has no known NID, skipped > -> > > > However, I can't figure out how to make this work for the Subject > Alternate Name. > > DogTag rejects the certificate with > > CA: Request Rejected - Subject Name Not Matched E=mymail at company.com > ,2.5.29.17=www.company.com,CN=server.... > For this error, if you enroll for a user cert, see the CA profile /var/lib/pki-ca/profiles/ca/caDualRAuserCert.cfg and change the default configuration for policyset.userCertSet.1.constraint.params.pattern=.*UID=.* to match your needs > > Is there a "NID" parameter than dogtag expects for SAN? > > > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6642 bytes Desc: S/MIME Cryptographic Signature URL: From gaiseric.vandal at gmail.com Tue Aug 31 19:54:59 2010 From: gaiseric.vandal at gmail.com (Gaiseric Vandal) Date: Tue, 31 Aug 2010 15:54:59 -0400 Subject: [Pki-users] DogTag 1.3 and Subject Alternate Name In-Reply-To: <4C7D5440.90803@redhat.com> References: <4C7D4D36.3060005@gmail.com> <4C7D5440.90803@redhat.com> Message-ID: <4C7D5E13.1030403@gmail.com> Hi I am having trouble with server certs, rather than user certs. My guess was that that when I go to the "Certificate System RA Services Page" and request a server cert, it is using the following profile /var/lib/pki-ca/profiles/ca/caServerCert.cfg This file includes the lines: policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl policyset.serverCertSet.1.constraint.name=Subject Name Constraint policyset.serverCertSet.1.constraint.params.pattern=.*CN=.* Which I take to mean that the subject must include a CN attribute somewhere. I also noticed that this policy file does not include options for e-mail (mail) or Subject Alternative Name, although the caDualRAuserCert.cfg does/ On the "Certificate System CA Services Page" (https://myserver:9443/ca/services) I see I have access to a full set of profiles. When I choose the serverCert request it seems OK with CSR's that include e-mail and SAN. This makes me suspect that the PKI RA is NOT using the profiles available to the CA. I also noticed during installation that the RA creates a sqlite database, and is not using the LDAP backend for requests that the CA uses. Thanks On 08/31/2010 03:13 PM, Marc Sauton wrote: > On 08/31/2010 11:43 AM, Gaiseric Vandal wrote: >> >> I have installed DogTag 1.3 Certificate Server (CA and RA) components >> on Fedora Core 11. >> >> I want to configure a server certificate with a Subject Alternate Name. >> >> >> I used openssl to create a private key and a certificate signing >> request on the server in question. >> >> openssl genrsa -out server1.key -des3 1024 >> openssl req -new -key server1.key -out server.csr >> >> >> I am prompted along the way to include an e-mail address and subject >> alternate name. Both are permitted but optional in my openssl.cnf file. >> >> I can look at the csr with >> openssl req -in server.csr -text >> >> >> >> >> By default, openssl by default recreates a req with the following line >> >> Subject: C=US, ST=California, L=MyCity, O=MyCompany, OU=IT, >> CN=server.company.com/subjectAltName=www.company.com/emailAddress=mymail at company.com >> >> >> >> >> You can see that e-mail and SAN are part of the CN attribute. >> >> I went to the "Certificate System RA Services Page" >> (https://myserver:12890) - > SSL End Users Services -> Server >> Enrollment -> Request Submission. I pasted the contents of the csr >> file into the web page. The administrator (i.e. me) gets e-mail >> notification of a certificate request, and follows the link to >> approve it. However if I have included either e-mail or SAN the >> request will fail because the subject name doesn't match. >> >> CA: Request Rejected - Subject Name Not Matched >> E=mymail at company.com,CN=server.company.com,OU=IT,O=My >> Company,L=MyCity,ST=California,C=US >> >> >> >> >> If I compare the dogtag error message to the original csr file I can >> see that dogtag expects a different syntax for e-mail. Dogtag >> expects it as a separate "E" attribute (It still seems to have >> translated the attributes appropriately but then complains the >> subject doesn't match.) I can work around this by either omitting >> e-mail in the csr altogether or explicitly setting the subject >> attribute with the "openssl req -subj" >> >> -> openssl req -new -key server.key -out server.csr -subj >> "/E=mymail at company.com,CN=server.company.com,OU=IT,O=My Company >> Name,L=MyCity,ST=California,C=US" >> Enter pass phrase for server.key: >> Subject Attribute E has no known NID, skipped >> -> >> >> >> However, I can't figure out how to make this work for the Subject >> Alternate Name. >> >> DogTag rejects the certificate with >> >> CA: Request Rejected - Subject Name Not Matched E=mymail at company.com >> ,2.5.29.17=www.company.com,CN=server.... >> > For this error, if you enroll for a user cert, see the CA profile > /var/lib/pki-ca/profiles/ca/caDualRAuserCert.cfg > and change the default configuration for > policyset.userCertSet.1.constraint.params.pattern=.*UID=.* > to match your needs > >> >> Is there a "NID" parameter than dogtag expects for SAN? >> >> >> >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msauton at redhat.com Tue Aug 31 20:23:01 2010 From: msauton at redhat.com (Marc Sauton) Date: Tue, 31 Aug 2010 13:23:01 -0700 Subject: [Pki-users] DogTag 1.3 and Subject Alternate Name In-Reply-To: <4C7D5E13.1030403@gmail.com> References: <4C7D4D36.3060005@gmail.com> <4C7D5440.90803@redhat.com> <4C7D5E13.1030403@gmail.com> Message-ID: <4C7D64A5.8090300@redhat.com> On 08/31/2010 12:54 PM, Gaiseric Vandal wrote: > Hi > > I am having trouble with server certs, rather than user certs. My > guess was that that when I go to the "Certificate System RA Services > Page" and request a server cert, it is using the following profile > > > /var/lib/pki-ca/profiles/ca/caServerCert.cfg > /var/lib/pki-ca/profiles/ca/caRAserverCert.cfg > > This file includes the lines: > > policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl > policyset.serverCertSet.1.constraint.name=Subject Name Constraint > policyset.serverCertSet.1.constraint.params.pattern=.*CN=.* and similar subject name constraint policyset.serverCertSet.1.constraint.params.pattern=CN=.* to customize and first verify with enrollment success, and then do the subj alt names part for the next troubleshooting > > > Which I take to mean that the subject must include a CN attribute > somewhere. I also noticed that this policy file does not include > options for e-mail (mail) or Subject Alternative Name, although the > caDualRAuserCert.cfg does/ > > On the "Certificate System CA Services Page" > (https://myserver:9443/ca/services) I see I have access to a full set > of profiles. When I choose the serverCert request it seems OK with > CSR's that include e-mail and SAN. > > > This makes me suspect that the PKI RA is NOT using the profiles > available to the CA. I also noticed during installation that the RA > creates a sqlite database, and is not using the LDAP backend for > requests that the CA uses. > > > > Thanks > > > On 08/31/2010 03:13 PM, Marc Sauton wrote: >> On 08/31/2010 11:43 AM, Gaiseric Vandal wrote: >>> >>> I have installed DogTag 1.3 Certificate Server (CA and RA) >>> components on Fedora Core 11. >>> >>> I want to configure a server certificate with a Subject Alternate Name. >>> >>> >>> I used openssl to create a private key and a certificate signing >>> request on the server in question. >>> >>> openssl genrsa -out server1.key -des3 1024 >>> openssl req -new -key server1.key -out server.csr >>> >>> >>> I am prompted along the way to include an e-mail address and subject >>> alternate name. Both are permitted but optional in my openssl.cnf file. >>> >>> I can look at the csr with >>> openssl req -in server.csr -text >>> >>> >>> >>> >>> By default, openssl by default recreates a req with the following line >>> >>> Subject: C=US, ST=California, L=MyCity, O=MyCompany, OU=IT, >>> CN=server.company.com/subjectAltName=www.company.com/emailAddress=mymail at company.com >>> >>> >>> >>> >>> You can see that e-mail and SAN are part of the CN attribute. >>> >>> I went to the "Certificate System RA Services Page" >>> (https://myserver:12890) - > SSL End Users Services -> Server >>> Enrollment -> Request Submission. I pasted the contents of the csr >>> file into the web page. The administrator (i.e. me) gets e-mail >>> notification of a certificate request, and follows the link to >>> approve it. However if I have included either e-mail or SAN the >>> request will fail because the subject name doesn't match. >>> >>> CA: Request Rejected - Subject Name Not Matched >>> E=mymail at company.com,CN=server.company.com,OU=IT,O=My >>> Company,L=MyCity,ST=California,C=US >>> >>> >>> >>> >>> If I compare the dogtag error message to the original csr file I can >>> see that dogtag expects a different syntax for e-mail. Dogtag >>> expects it as a separate "E" attribute (It still seems to have >>> translated the attributes appropriately but then complains the >>> subject doesn't match.) I can work around this by either >>> omitting e-mail in the csr altogether or explicitly setting the >>> subject attribute with the "openssl req -subj" >>> >>> -> openssl req -new -key server.key -out server.csr -subj >>> "/E=mymail at company.com,CN=server.company.com,OU=IT,O=My Company >>> Name,L=MyCity,ST=California,C=US" >>> Enter pass phrase for server.key: >>> Subject Attribute E has no known NID, skipped >>> -> >>> >>> >>> However, I can't figure out how to make this work for the Subject >>> Alternate Name. >>> >>> DogTag rejects the certificate with >>> >>> CA: Request Rejected - Subject Name Not Matched E=mymail at company.com >>> ,2.5.29.17=www.company.com,CN=server.... >>> >> For this error, if you enroll for a user cert, see the CA profile >> /var/lib/pki-ca/profiles/ca/caDualRAuserCert.cfg >> and change the default configuration for >> policyset.userCertSet.1.constraint.params.pattern=.*UID=.* >> to match your needs >> >>> >>> Is there a "NID" parameter than dogtag expects for SAN? >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pki-users mailing list >>> Pki-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-users >>> >> > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6642 bytes Desc: S/MIME Cryptographic Signature URL: