Problems with Dogtag and CA cert signed by External CA
by Dwayne MacKinnon
Hi all,
A helpful fellow called alee on #dogtag-pki suggested I write the list. I've
been playing with dogtag-pki-9.0.0-10 on 64-bit Fedora 17.
I'm looking to use dogtag to run a subordinate CA that does all our everyday
PKI stuff. So when I used pki-create and went into the webform, I went the
"create a csr" route and signed it using a root CA I'd set up using openssl.
Everything seemed to work out fine, until I got to the point where I was
restarting pki-cad (using systemctl restart pki-cad(a)pki-ca.service). It
wouldn't start.
With alee's help I tracked it down to a failure of SystemCertsVerification
during the selftests.
He asked me to submit my debug log to the list, so here it is.
Cheers,
DMK
11 years, 9 months
Announcing Dogtag 10 Beta 2 Release
by Ade Lee
The Dogtag team is proud to announce version Dogtag v10.0.0 beta 2.
A build is available for Fedora 18 in the updates-testing repo. Please
try it out and provide karma to move it to the F18 stable repo.
Daily developer builds for Fedora 17 and 18 are available at
http://nkinder.fedorapeople.org/dogtag-devel/fedora/
== Build Versions ==
pki-core-10.0.0-0.48.b2.fc18
pki-ra-10.0.0-0.10.b2.fc18
pki-tps-10.0.0-0.10.b2.fc18
dogtag-pki-10.0.0-0.13.b2.fc18
dogtag-pki-theme-10.0.0-0.4.b2.fc18
pki-console-10.0.0-0.10.b2.fc18
== Highlights since Dogtag v. 10.0.0 beta 1 (Oct 9 2012) ==
* Selinux policy moved into system selinux policy. For F18, pki-selinux
will no longer be built and delivered by the dogtag team. The PKI
policy will instead be managed by the selinux base packages team.
* Added option to install schema on a clone, rather than simply
replicating it. This is to resolve an IPA issue when replicating from a
non-merged to a merged database.
* Restricted AJP to allow access from localhost only by default. This
is an IPA reported issue.
* Changes to allow the TPS and RA to install and configure correctly.
* Enabled Tomcat security manager and added mechanism to configure
custom security policy.
* Added CLI tools to obtain security domain information and install
tokens.
* Refactored REST client classes to support multiple operations over
authenticated HTTP session.
* Added automatic recovery to the LDAP modification listener.
* Added login service to protect REST services including certificate
operations, key operations, security domain, TKS and OCSP.
* Added option to pkispawn to exit before configuration, in case the
installer wants to go through the UI configuration panels. In this way,
pkispawn can be operated like pkicreate/pkisilent.
* Removed version numbers from jar files to comply with Fedora packaging
recommendations.
== Notes for F17 ==
* Only developer builds are available for F17.
* F17 tomcat used to have a bug in the way it handles pid files.
https://bugzilla.redhat.com/show_bug.cgi?id=863307. Make sure that you
have at least tomcat-7.0.32-1.fc17.
== Feedback ==
Please provide comments, bugs and other feedback via the pki-devel
mailing list: http://www.redhat.com/mailman/listinfo/pki-devel
== Detailed Changelog ==
akoneru (1):
1485a05 Fix for ticket 384 - Incorrect profiles path referenced
alee (15):
80ac796 Fix symkey build dependency
65c17da Update to b2 release
7c105a6 Restrict AJP to localhost only by default
3908d96 Added obsoletes for pki-selinux
278ee60 changes to remove pki-selinux from f18 build
1c45197 Provide option to install, rather than replicate schema to clone
40bcc2c Reorder VLV indexing for clones to avoid errors
643c089 Fixes to get TPS to configure correctly
d6634a7 Reverted to old interface and httpclient for installation token.
2a43f48 Added net-tools dependency
35eb608 changes to remind folks not to use pkicreate/pkiremove
8a2d342 Update tomcatjss dependency
283af42 Added pki_tomcat_script_t type and rules for upgraded instances
c7c2b6c New selinux interface needed for certmonger directory access
c494bd0 Added pki_tomcat_cert_t type and interface to access it
edewata (16):
c1aa8b2 Enabled authentication for key services.
748605a Fixed synchronization problem in CertificateRepository.
5eab7fe Enabled Tomcat security manager.
9c17ef4 Refactored GetDomainXML servlet.
5bb7933 Added REST interface to get domain info.
6359021 Enabled account service for TKS and OCSP.
8687740 Added conditions for security domain REST service.
7ec6c91 Fixed error handling in RetrieveModificationsTask.
2d3d561 Fixed KRA test.
c1f9b39 Enabled realm authentication for certificate requests.
1723a2e Added REST account service.
98ad9c1 Added PKIPrincipal.
4300459 Added PKIConnection.
8973480 Refactored GetCookie servlet.
168d954 Enabled authentication for security domain REST interface.
212ab82 Return to d9 behavior for RetrieveModificationsTask
mharmsen (2):
a957a3d Allow a PKI instance to be installed/configured independently
8d77b52 Removal of version numbers from jar file names
11 years, 11 months
Dogtag and certificate VPN
by Ritter, Nicholas
Is anyone using, or has tested, Dogtag with certificate based VPN? And more specifically with Cisco ASA Anyconnect and IPSEC VPN?
I searched through the dogtag mailing list archive and the Cisco forums and found someone tried to do this in 2010 and had problems that I can only assume there was no resolution to. The last posting I saw was someone giving the blanket vendor reason of "Cisco does not support that CA". Given that there has not been a posting since, and that was two years ago, I was curious if anyone had tested/implemented it?
Nick
12 years
Re: [Pki-users] Dogtag and certificate VPN
by Jennings, Charles
I can tell you that I have used DogTag 1.3 with Cisco based IPSec VPNs
between routers (not using ASAs) with no problem - other than - I had to
change the RSA hashing algorithm at setup to utilize SHA-1 instead of
the default of SHA-256 - which the cisco routers I was testing with did
not support.
Charles Jennings
From: pki-users-bounces(a)redhat.com [mailto:pki-users-bounces@redhat.com]
On Behalf Of Ritter, Nicholas
Sent: Thursday, October 11, 2012 9:20 AM
To: pki-users(a)redhat.com
Subject: [Pki-users] Dogtag and certificate VPN
Is anyone using, or has tested, Dogtag with certificate based VPN? And
more specifically with Cisco ASA Anyconnect and IPSEC VPN?
I searched through the dogtag mailing list archive and the Cisco forums
and found someone tried to do this in 2010 and had problems that I can
only assume there was no resolution to. The last posting I saw was
someone giving the blanket vendor reason of "Cisco does not support that
CA". Given that there has not been a posting since, and that was two
years ago, I was curious if anyone had tested/implemented it?
Nick
12 years
Re: [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server
by Christina Fu
Hi Jamil,
We branched off of JSS 4.2.6 and created several patches ever since.
Merging with upstream JSS (4.3) has been planned to be done within the
next year also. Until then, we are not able to provide information with
confidence on how JSS4.3 would work with our current releases. If any
Dogtag community member has tried and has answer for you, it would be
great.
Christina
On 10/10/2012 09:54 AM, Nimeh, Jamil wrote:
>
> [Re-reply to include pki-devel(a)redhat.com <mailto:pki-devel@redhat.com>]
>
> Hi Christina, sorry for taking so long to get back to you. I can file
> this against JSS, but given that it's a down-rev version (4.2.6) and
> appears to be fixed in JSS 4.3, is it worth filing this?
>
> I guess the bigger question that affects SHA-2 algorithms as they are
> implemented in Dogtag is whether or not I can safely use JSS 4.3 with
> Dogtag 9.0.x? 4.2.6 is what appears to be the latest rev in the F15
> yum repositories. Do you (or anyone on your team maybe) know if there
> are incompatibilities between JSS 4.2.6 and 4.3 that would break a
> Dogtag 9 installation?
>
> If it can work the areas that this would affect would be:
>
> * Proper creation of SCEP CertRep messages when using SHA-2 algs
> * The ability to sign OCSP responses using something other than
> SHA-1 (can that be changed? I don't see a tuneable for this)
> * The ability to submit CMC revocation messages using SHA-2 and
> have it properly validated before acting on it in the CA.
>
> There might be other areas as well (maybe in other CMC related
> functions) but those three areas are the ones I've run into.
>
>
> Thanks,
>
> Jamil
>
> ------------------------------------------------------------------------
> *From:* pki-users-bounces(a)redhat.com [pki-users-bounces(a)redhat.com] on
> behalf of Christina Fu [cfu(a)redhat.com]
> *Sent:* Monday, October 01, 2012 1:22 PM
> *To:* pki-users(a)redhat.com
> *Subject:* Re: [Pki-users] SHA-256 signed CMC revocation messages
> failing to verify on server
>
> Hi Jamil,
>
> I see the issue now. I agree there is an issue with the OID. In
> fact, the hashalg (2) is missing from not just SHA256, but also SHA384
> and SHA512 as well.
>
> Please go ahead and file a bug for JSS so it could be scheduled for
> future release. It will probably be automatically assigned to me by
> default.
>
> thanks,
> Christina
>
> On 09/27/2012 09:34 AM, Christina Fu wrote:
>> Hi Jamil,
>>
>> I am running a variant of jss-4.2.6-23 (with one extra patch that I
>> have not had time to push/build, but it has nothing to do with your
>> suspected area). For nss, I'm running nss-3.13.5-8.el5. Again, I
>> develop on RHEL.
>>
>> Yes, if you'd send in your code with precise reproducing steps, I
>> might be able to look into it sooner.
>>
>> Christina
>>
>> On 09/25/2012 11:10 PM, Nimeh, Jamil wrote:
>>> Hi Christina, thank you very much for getting back to me.
>>>
>>> I haven't seen the problem with the PKCS#1 SHA-256 with RSA OID.
>>> That seems to work across the board with JSS and Dogtag (otherwise I
>>> could never sign a cert with SHA-256, I suppose). I'd be curious to
>>> know what version of JSS is on your RHEL/RHCS8.1 machine, and
>>> perhaps what NSS version. On my Fedora box it's JSS 4.2.6 and NSS
>>> 3.13.4. Maybe something different between the bits we're running?
>>>
>>> I've run into the issue when a PKCS#7 or CMS signedData message is
>>> created. In those cases, the SHA-256 OID would normally be asserted
>>> in two locations:
>>> 1. In the DigestAlgorithmIdentifiers segment of the SignedData
>>> object (see RFC 5652 5.1): CMS/PKCS#7 objects have it properly
>>> asserted here.
>>>
>>> 2. In the DigestAlgorithmIdentifier portion of the SignerInfo (see
>>> RFC 5652 5.3): This is where the OID gets messed up with SHA-2
>>> algs. Since there is only one signer, the
>>> DigestAlgorithmIdentifiers section at the beginning would have only
>>> one OID, the SHA-256 one, and that OID should be repeated again in
>>> the SignerInfo.
>>>
>>> What happens though is that the SignerInfo's
>>> DigestAlgorithmIdentifier will show up with an OID of
>>> 2.16.840.1.101.3.4.1 when it should be 2.16.840.1.101.3.4.2.1. This
>>> appears to happen with JSS 4.2.6, but not with JSS 4.3. But 4.2.6
>>> is what comes down when the dogtag packages are pulled with yum, so
>>> I wasn't sure if I could pop in a newer JSS safely.
>>>
>>> Tomorrow I'll take my doctored up CMCRevoke and cook up two
>>> messages, one where I load the 4.2.6 JSS and one where I do 4.3 and
>>> I'll send you the DER encodings so you can see what I'm talking
>>> about. I don't recall, but I think the bug report for 824624 might
>>> have sample SCEP CertRep messages from the CA, which show the issue
>>> using PKCS#7.
>>>
>>> Once again, thank you very much for taking the time to look at this.
>>>
>>> --Jamil
>>>
>>> ------------------------------------------------------------------------
>>> *From:* pki-users-bounces(a)redhat.com [pki-users-bounces(a)redhat.com]
>>> on behalf of Christina Fu [cfu(a)redhat.com]
>>> *Sent:* Tuesday, September 25, 2012 8:46 PM
>>> *To:* pki-users(a)redhat.com
>>> *Subject:* Re: [Pki-users] SHA-256 signed CMC revocation messages
>>> failing to verify on server
>>>
>>> Hi Jamil,
>>>
>>> I tried to reproduce your issue, but I seemed to be able to generate
>>> CMC revocation request with SHA-256 digest. I have to admit that my
>>> main development machine is RHEL and I work on RHCS8.1 tree.
>>>
>>> I changed all "SHA1" to "SHA256" in CMCRevoke.java (with the
>>> exception with DSA), compiled, and it just worked. Did you do
>>> anything different?
>>>
>>> I could see in dumpasn1 where SHA245 is in place:
>>> C-Sequence (13)
>>> Object Identifier (9)
>>> 1 2 840 113549 1 1 11 (PKCS #1 SHA-256 With RSA Encryption)
>>> NULL (0)
>>> Christina
>>>
>>> On 09/19/2012 11:19 AM, Christina Fu wrote:
>>>> Hi Jamil,
>>>>
>>>> We made an effort to support SHA2 where we can but might have
>>>> missed a few places. I'll look into this and hopefully be able to
>>>> get back to you in a few days.
>>>>
>>>> thanks,
>>>> Christina
>>>>
>>>> On 09/19/2012 12:44 AM, Nimeh, Jamil wrote:
>>>>>
>>>>> Hello Dogtag Gurus,
>>>>>
>>>>> I have been trying to issue CMC revocation messages signed with
>>>>> SHA-256, but the server fails to validate the message in the
>>>>> CMCAuth java policy module. If I leave all fields the same but
>>>>> change the signature algorithm to SHA-1 then everything seems to
>>>>> work fine.
>>>>>
>>>>> I suspect this is another side-effect of the root-cause for bug
>>>>> 824624. It seems like in certain cases with JSS 4.2.6 when PKCS#7
>>>>> messages are created using any of the SHA-2 variants, the OIDs get
>>>>> messed up. This happened with SCEP responses from the CA (the bug
>>>>> referenced above) and I had it happen with the CMC revoke
>>>>> modifications I made. The latter issue was fixed by pulling down
>>>>> JSS 4.3 and loading that jar in the classpath for the modified
>>>>> CMCRevoke tool. However, on the server side I ended up seeing
>>>>> verification failures.
>>>>>
>>>>> I'm running pki-common-9.0.20, jss 4.2.6, and NSS 3.13.4. At one
>>>>> point I had heard that Dogtag 9.0.X wasn't 100% safe to run with
>>>>> JSS 4.3 or later. Is that still the case with the latest 9.0
>>>>> packages?
>>>>>
>>>>>
>>>>> Has anyone had any success generating these CMC messages using
>>>>> SHA-2 hash algs and getting Dogtag to accept them?
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jamil
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pki-users mailing list
>>>>> Pki-users(a)redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/pki-users
>>>>
>>>>
>>>> _______________________________________________
>>>> Pki-users mailing list
>>>> Pki-users(a)redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pki-users
>>>
>>
>>
>> _______________________________________________
>> Pki-users mailing list
>> Pki-users(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-users
>
12 years
Announcing Dogtag 10.0.0 beta 1 release
by Ade Lee
The Dogtag team is proud to announce version Dogtag v10.0.0 beta 1.
A build is available for Fedora 18 in the updates-testing repo. Please
try it out and provide karma to move it to the F18 stable repo.
Daily developer builds for Fedora 17 and 18 are available at
http://nkinder.fedorapeople.org/dogtag-devel/fedora/
== Build Versions ==
pki-core-10.0.0-0.43.b1.fc18
pki-ra-10.0.0-0.9.b1.fc18
pki-tps-10.0.0-0.9.b1.fc18
dogtag-pki-10.0.0-0.10.b1.fc18
dogtag-pki-theme-10.0.0-0.2.b1.fc18
pki-console-10.0.0-0.8.b1.fc18
== Highlights since Dogtag v. 10.0.0 alpha 2 (Oct 1 2012) ==
* Merged pki-silent into pki-server.
* Added Provides to packages replacing obsolete packages.
* Added needed link for updated d9 -> d10 instances. Found in IPA
testing.
* Backed up CS.cfg before upgrading from d9 -> d10
* New selinux policy for all components. The Java components now take
advantage of a tomcat domain defined in the base selinux policy, and
the RA/TPS policies have been cleaned up considerably. The policy that is
now delivered is very close to the final version that will be delivered
in the base policy. That will be a deliverable for beta 2.
* Selinux context for startup scripts for all components set so that
runcon is not required.
* Cleaned up lock and pid files generation and removal for java
processes.
* Rebuilt packages against the latest F18 base selinux policy packages
to resolve an issue in installing pki-selinux due to removal of a
boolean in F18 base selinux policies. This issue was reported by IPA.
== Notes for F17 ==
* F17 requires an selinux version that is still in updates-testing.
Enable this repo to upgrade accordingly.
* F17 tomcat has a bug in the way it handles pid files.
https://bugzilla.redhat.com/show_bug.cgi?id=863307. Prior to creating
an instance, you need to perform the following workaround:
In the file, /usr/sbin/tomcat-sysd, change the line:
export CATALINA_PID="/var/run/${NAME}.pid"
to:
export CATALINA_PID="${CATALINA_PID:-/var/run/${NAME}.pid}"
== Feedback ==
Please provide comments, bugs and other feedback via the pki-devel
mailing list: http://www.redhat.com/mailman/listinfo/pki-devel
== Detailed Changelog ==
Ade Lee (11):
5ef10ba Update selinux-policy version to fix error from latest policy
81596ba fix spec typo
919434b Added build requires for version of selinux-policy-devel
5014442 Update release to b1
9cd11bc Fix name of CS.cfg backup file
63237d3 Backup CS.cfg before d10 update
da73f97 Changes to start pki_ra and pki_tps in correct context
6e79c7c add selinux context for pkidaemon, remove unneeded pid/lock code
f542060 move common policy into tps, ra templates
dbc6dec Use the tomcat selinux domain for the Java processes
3d5dc3b Added needed link for updated d9 -> d10 instances
Endi Dewata (3):
23c70bd Merged pki-silent into pki-server.
79a3d82 Renamed "shared" folder to "server".
753d55e Added Provides to packages replacing obsolete packages.
12 years
Server Error at RA installation
by pki tech
Hi Experts,
I'm stuck with an RA installation with Fedora DogTag 9.0 over Fedora 15.
I got my root CA and CA instances working fine. Then I started installing
the RA. As it progresses, I was prompted to enter the security domain. So I
set the security domain URL and certificate chain was loaded. As I pressed
next, I got this error as the response.
----------------------------------------------------------------------------------------------------
Internal Server Error
------------------------
The server encountered an internal error or misconfiguration and was unable
to complete your request.
Please contact the server administrator, you example com and inform them of
the time the error occurred, and anything you might have done that may have
caused the error.
More information about this error may be available in the server error log.
----------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------
pki-ra error log
---------------------------
[Sun Sep 30 23:23:25 2012] [info] Subsequent (No.18) HTTPS request received
for child 10 (server ra.example.com:12890)
GET /ca/admin/ca/getDomainXML HTTP/1.0
port: 9445
addr='ca.example.com'
family='2'
-- SSL3: Server Certificate Validated.
PR_Write wrote 42 bytes from bigBuf
bytes: [GET /ca/admin/ca/getDomainXML HTTP/1.0
]
do_writes shutting down send socket
do_writes exiting with (failure = 0)
connection 1 read 252 bytes (252 total).
these bytes read:
connection 1 read 252 bytes total. -----------------------------
[Sun Sep 30 23:23:25 2012] [error] [client 192.168.3.203] Could not find
httpd.xml in /usr/sbin/ at
/var/lib/pki-ra/lib/perl/PKI/RA/DisplayCertChainPanel.pm line 228\n,
referer: https://ra.example.com:12890/ra/admin/console/config/wizard
[Sun Sep 30 23:23:25 2012] [info] Connection to child 10 closed (server
ra.iris.lk:12890, client 192.168.3.203)
----------------------------------------------------------------------------------------------------------------------------
I Tried reinstalling the RA instance, but got the same result.
Highly Appreciated If some expert could help me on this.
12 years
Announcing Dogtag 10.0.0 alpha 2 release
by Ade Lee
The Dogtag team is proud to announce version Dogtag v10.0.0 alpha 2.
A build is available for Fedora 18 in the updates-testing repo. Please
try it out and provide karma to move it to the F18 stable repo.
Daily developer builds for Fedora 17 and 18 are available at
http://nkinder.fedorapeople.org/dogtag-devel/fedora/
== Build Versions ==
pki-core-10.0.0-0.37.a2.fc18
pki-ra-10.0.0-0.8.a2.fc18
pki-tps-10.0.0-0.8.a2.fc18
dogtag-pki-10.0.0-0.9.a2.fc18
dogtag-pki-theme-10.0.0-0.2.a2.fc18
pki-console-10.0.0-0.8.a2.fc18
== Highlights since Dogtag v. 10.0.0 alpha 1 (Sept 14 2012) ==
* Dogtag 10 can now clone from Dogtag 9 masters. We will fall back to
the old installation servlet if needed. (**)
* Startup state of a server can be determined from the getStatus()
servlet (**)
* Consistent database user provided during installation for client
authentication (used in IPA merged database install)
* Fixed package dependency issue with pki-symkey (**)
* pki-setup merged into pki-server (**)
* Audit Cert Renewal time extended to two years (**)
* Versioning added to jar manifest files and VERSION file and reported
in getStatus
* ECC enhancements in DRM and TMS environment
* Addition of time based searches in preparation for randomized serial
numbers
* Enhanced escaping of LDAP attributes
* Improved transition control for token operations in the TPS.
** denotes IPA related/reported issue
== Feedback ==
Please provide comments, bugs and other feedback via the pki-devel
mailing list: http://www.redhat.com/mailman/listinfo/pki-devel
== Detailed Changelog ==
Ade Lee (4):
761a047 Updated release to a2
854ecce fall back to old interface for installtoken if needed
11e05d3 Use getStatus servlet to provide startup status
e1666df Changes to use standard dbuser
Andrew Wnuk (1):
f944641 time based searches
Christina Fu (5):
7b3df7e https://fedorahosted.org/pki/ticket/252 - TMS - ECC Key Recovery
528fda5 TMS key recovery part of - Bug 737122 - DRM: during archiving
and recovering, wrapping unwrapping keys should be done in the token
f4ecf48 (fixed warning for) task #304 TMS ECC infrastructure (enrollment
with client-side and server-side key generation, and key archival)
e689561 https://fedorahosted.org/pki/ticket/304 TMS ECC infrastructure
(enrollment with client-side and server-side key generation, and key
archival)
6257d32 https://fedorahosted.org/pki/ticket/304 TMS ECC infrastructure
(enrollment with client-side and server-side key generation, and key
archival)
Endi Dewata (11):
f81718c Using RPM version number in CMake.
aa1c7e7 Added package checking for pkispawn.
87d290d Added version number into server status.
9368ef4 Added VERSION file.
1726794 Renamed escapeDN() into escapeRDNValue().
4ba74f7 Merged pki-setup into pki-server.
156ba56 Added DN and filter escaping in ConfigurationUtils.
947ab8a Removed duplicate DN escaping methods.
715d89d Added DN and filter escaping in UGSubsystem.
7b737b2 Fixed conflicting log4j.properties.
8ed86a7 Fixed problems with optional pki-symkey.
Jack Magne (1):
9173b43 Provide default for operations transition list, # 858816.
Matthew Harmsen (2):
d450525 Correctly resolve symlinks in subdirectories
f5b8ea5 Audit Cert Renewal
12 years
SHA-256 signed CMC revocation messages failing to verify on server
by Nimeh, Jamil
Hello Dogtag Gurus,
I have been trying to issue CMC revocation messages signed with SHA-256, but the server fails to validate the message in the CMCAuth java policy module. If I leave all fields the same but change the signature algorithm to SHA-1 then everything seems to work fine.
I suspect this is another side-effect of the root-cause for bug 824624. It seems like in certain cases with JSS 4.2.6 when PKCS#7 messages are created using any of the SHA-2 variants, the OIDs get messed up. This happened with SCEP responses from the CA (the bug referenced above) and I had it happen with the CMC revoke modifications I made. The latter issue was fixed by pulling down JSS 4.3 and loading that jar in the classpath for the modified CMCRevoke tool. However, on the server side I ended up seeing verification failures.
I'm running pki-common-9.0.20, jss 4.2.6, and NSS 3.13.4. At one point I had heard that Dogtag 9.0.X wasn't 100% safe to run with JSS 4.3 or later. Is that still the case with the latest 9.0 packages?
Has anyone had any success generating these CMC messages using SHA-2 hash algs and getting Dogtag to accept them?
Thanks,
Jamil
12 years
DogTag CS for CentOS or later Fedora Versions
by pki tech
Hi all,
Im planning to go for a Large scale CA implementation with Current DogTag
release 9.0 on Fedora 15. But the main worry that i have is the Fedora
Support Cycle, which makes an doubt on the security of the Systems at the
long run.
Are there anyone who has successfully deployed a complete CA, OCSP and RA
based solution on CentOS platform? If so I can continue my implementations
with CentOS. What I found while googling was there are package issues while
deploying DogTag over CentOS.
Although the main site says DogTag 9.0 is tested for up to only Fedora 15,
I found rpms for the subsystems pki-ca, pki-ocsp and pki-ra in other Fedora
repositories for example Fedora 16. So will it be possible to have a stable
PKI infrastructure over Fedora 16 with DogTag 9.0 (DogTag 10 is still in
alpha stage)
In the meantime I'm locally testing all the functionalities of DogTag 9.0
over Fedora 16 and CentOS. Will update as I progress.
Thank you.
12 years
