| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
password in password.conf
This patch allows config panel ModulePanel to log into "Other Modules" (unsupported modules).
Also to note: the modules passwords appear to be stored in pwcache.conf, not password.conf.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the ECC plan and the different phases, please refer to
http://pki.fedoraproject.org/wiki/ECC_in_Dogtag
Design for each phase is on the same wiki page.
Note: the designs beyond phase 2 were more like a brain dump. Although I said
"Do Not Review," you are free to take a peak at what's intended down the road.
I will go back and take a closer look and refine/adjust the designs when I
begin implementation for each new phase.
What you need to know:
* Problem 1 - nethsm issue:
On the server side, if you turn on FIPS mode, in addition to nethsm, you need
to attach certicom as well to have ECC SSL working on the server side. This
problem has already been reported to Thales last year and they said they'd look
into putting the item on their next release. Recently through a different
contact, we learned there might be a way to "turn it on" (still waiting for
their further instruction)
* Problem 2- Certicom issue:
This is a show-stopper for deployment. Initially, on the client side, I used Kai's special
version of Xulrunner/Firefox, attached to Certicom token, so that the CRMF
requests can be generated with key archival option. However, I encountered
(or, re-encountered) an issue with certicom token. Certicom generates ECC keys
with the wrong format (not PKCS7 conforming), which makes ECC key archival
impossible on the server side if you use non-certicom token with DRM (but we
expect an HSM in most product deployment). I have contacted Certicom for this
issue, and they confirmed that they indeed have such issue. We are hoping they will fix it.
But then you might ask, "I thought I saw some ECC enrollment
profiles/javascripts being checked in? How were the tests done?" The tests for
those profiles were done against this ECC key archival/recovery DRM prototype I
implemented last year (needs to be turned on manually in 8.1), where I
"cheated" (yeah, that's why it's called a prototype) by decrypting the private
key in the CRMF on DRM, and then manipulating the byte array to strip off the
offending bytes before archival.
In the real, non-prototype implementation, which is what's in this patch, for
security reasons, private keys are unwrapped directly onto the token during key
archival, so there is no way to manipulate the keys in memory and bypass the
Certicom issue.
A word about Kai's special version of Xulrunner/Firefox. It is not yet
publicly available (due out in Firefox 10.0.4 on RHEL 5.8).
* Problem 3- Firefox with nethsm issue:
Another option was to connect Kai's special version firefox with an HSM to test
my DRM/JSS code. However, for whatever reason, I could not get SSL going
between such Firefox and ECC CA ( I did not try very hard though, as I have one
other option -- writing my own ECC CRMF generation tool. I might come back to
try the nethsm Firefox idea later)
My solution (how I work on this official implementation):
* I hacked up a ECC CRMF tool by taking the CRMFPopClient (existing in current
releases), gutting out the RSA part of the code, and replacing it with ECC
code. I call it CRMFPopClientEC. Two types of ECC key pairs could be
generated: ECDSA or ECDH (That's another benefit of writing my own tool -- I
don't know if you can select which type to generate in the Javascript... maybe
you can, I just don't know). I'm in no way condoning archival of signing
keys!! This is just a test tool.
This tool takes a curve name as option (along with others), generates an ECC
key pair, crafts up an CRMF request with key archival option, and sends request
directly to the specified CA. You will see a "Deferred" message in the HTML
response (see attachment for example)
Once CA agent approves the request, the archival request goes to DRM and the
user private key is archived.
For recovery, DRM agent selects key recovery, etc, and you get your pkcs12.
I did some sanity test with the pkcs12 recovered:
* Import the recovered pkcs12 into a certicom library:
pk12util -d . -h "Certicom FIPS Cert/Key Services" -i userEC.p12
I also tested by retrieving a p12, importing it into a browser, and adding the
user as an agent and the user could act as agent via ssl client auth to the CA.
Finally, much of the RSA-centric code had been cleared out of the way at the
time when I worked on the DRM ECC prototype, so you don't see much of that in
this round.
How do you test? Well, unless you want to use my CRMFPopClientEC tool hooked up
with a nethsm (like I did), or write your own tool, you can't really test it
until Certicom fixes their issue. (BTW CRMFPopClientEC can also be changed to
work with ceriticom, although you would run into the same issue I mentioned
above)
|
|
|
|
|
|
|
|
|
| |
Previously the source code was located inside a pki folder.
This folder was created during svn migration and is no longer
needed. This folder has now been removed and the contents have
been moved up one level.
Ticket #131
|
|
|
|
| |
Top-level CMakeLists.txt & script file changes for core, kra, ocsp, and tks
|
|
|
|
| |
Spec file changes for tks, ocsp, kra
|
|
|
|
|
|
|
|
|
|
| |
Tomcat6 has changed the changed the location of the TOMCAT_LOG, and
it should no longer point to catalina.out. This initially caused
dogtag to break because the code to chown TOMCAT_LOG to TOMCAT_USER
was removed. Added code to spec file to fix existing instances.
Also fixed error in spec file. Incorrect selinux patch was being
applied for f17.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Migrated the following bugs:
- Bugzilla Bug #747381 - After the migration (7.1->8.1) CA agent page
displays admin cert request with authtime attribute twice
- Bugzilla Bug #747019 - Migrated policy requests from 7.1->8.1 displays
issuedcerts and cert_Info params as base 64 blobs.
- Bugzilla Bug #757848 - DRM re-key tool: introduces a blank line in the
middle of an ldif entry.
- Resolved Bugzilla Bug #801840 - pki_silent.template missing opening brace
for ca_external variable
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The mechanism for getting an ldap connection to the internaldb was incorrect,
both in the Security Domain Session Table and the DatabasePanel. As a result,
connections to the internaldb failed for accessing the security domain session
table and when trying to clone a master which connects to its database using
client auth.
The thread that handles reading the security domain session table is now only
instantiated when running on a configured security domain master.
Additionally, needed acls for the client auth certificate ldap user have been
moved to manager.ldif. This includes acls to allow creation and management of
replication agreements and replication users (now being created under
ou=csusers, cn=config)
Added logs to show when ldif import errors occur. Also made sure to write and
remove master ldap password for use in replication.
Ticket #5
Conflicts resolved:
pki/base/common/src/com/netscape/cms/servlet/csadmin/AdminAuthenticatePanel.java
pki/base/common/src/com/netscape/cms/servlet/csadmin/DatabasePanel.java
pki/base/common/src/com/netscape/cms/servlet/csadmin/LDAPSecurityDomainSessionTable.java
pki/base/common/src/com/netscape/cms/servlet/csadmin/RestoreKeyCertPanel.java
pki/base/common/src/com/netscape/cms/servlet/csadmin/WizardPanelBase.java
pki/base/migrate/80/MigrateSecurityDomain.java
pki/base/util/src/com/netscape/cmsutil/ldap/LDAPUtil.java
|
|
|
|
| |
Bugzilla Bug #767800 - Firefox Launcher on Panel being modified for all users.
|
|
|
|
|
|
| |
Configuration wizard should provide option to issue ECC credentials for admin during ECC CA configuration.
Bug #784387.
|
| |
|
| |
|
|
|
|
|
|
| |
RSA should be default selection for transport, storage, and audit keys till ECC is fully implemented.
Bug #787806.
|
|
|
|
|
|
| |
Added platform-dependent patches for SELinux component
Bugzilla Bug #739708 - Selinux fix for ephemeral ports (F16)
Bugzilla Bug #795966 - pki-selinux policy is kind of a mess (F17)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a subsystem is configured, a user is created to facilitate communication
between subsystems. This user is created on the security domain ca, and is
has the subsystem certificate in its user record.
This user will be reused as a user that can talk to the database using the
subsystem certificate for client auth. To do this, this patch does the following:
1. If not the security domain master CA, adds this user to the subsystem, and
adds the subsystem cert.
2. Adds the subsystem cert subject dn to the user's record in the seeAlso attribute
3. Adds acis for this user for the $basedn and for cn=config (for VLV searches)
By default, this user and acls will be added when the system is configured.
To actually use the user and client auth, more config steps are required. They
will be doc'ed in https://fedorahosted.org/pki/ticket/5
|
| |
|
|
|
|
| |
(see https://fedorahosted.org/pki/ticket/104)
|
|
|
|
| |
Addresses java_exec_t issue in BZ 795966
|
|
|
|
|
|
| |
This patch provides two sample ECC certificate profiles.
Bug: 223358.
|
|
|
|
|
|
| |
This patch provides an option for certificate profiles to allow them to automatically create enrollment pages which are used to generate new signing and encryption certificate requests.
Bug: 703608.
|
|
|
|
|
|
| |
This patch provides an option for certificate profiles to allow them to automatically create enrollment pages which are used to generate new signing and encryption certificate requests.
Bug: 703608.
|
|
|
|
|
|
| |
This patch resolves issue of "Agent-Authenticated File Signing" enrollment altering some file hashes.
Bug: 771768.
|
|\
| |
| |
| | |
DOGTAG_9_BRANCH
|
| |
| |
| |
| |
| |
| |
| | |
CMakeLists.txt file was changed to account for the removal of
empty directories from the source code.
Bugzilla Bug #782953
|
| |
| |
| |
| |
| |
| | |
not cause server to shutdown as expected
There are two issues being fixed: 1. The variable, r, returned by verifySystemCertByTag() gets overwritten by the next return value in a while loop. The problem affects both java subsystems and TPS. 2. In the TPS system, within a while loop that calls verifySystemCertByNickname(), one condition does a "continue" without advancing to the next token, causing an infinite loop under that condition. Adding a PL_strtok_r(NULL, ",", &lasts); call resolves the issue.
|
|/
|
|
|
|
| |
CertNickName in the audit output
The issue was that the parameter ocsp.cert.signing.certusage=StatusResponder was missing the "certusage" component in CS.cfg.in. Adding it fixed the problem. cert nickname is added automatically at installation/configuration.
|
|
|
|
|
|
|
| |
This patch resolves multiple issues related to paging on request, certificate, and key lists.
It also provides consistent behavior across all lists.
Bug: 768138
|
|
|
|
|
|
|
| |
This patch resolves multiple issues related to use of big numbers on CA and DRM
It also provides a fix for incomplete recovery requests causing null pointer exception.
Bugs: 756133, 758505.
|
|
|
|
|
|
| |
FreeIPA install
Modified sslget doIO() function to be able to handle small reads.
|
|
|
|
| |
git-svn-id: svn+ssh://svn.fedorahosted.org/svn/pki/branches/DOGTAG_9_BRANCH@2293 c9f7a03b-bd48-0410-a16d-cbbf54688b0b
|
|
|
|
| |
git-svn-id: svn+ssh://svn.fedorahosted.org/svn/pki/tags/DOGTAG_9_0_FEDORA_15_16_17_20111028@2279 c9f7a03b-bd48-0410-a16d-cbbf54688b0b
|
|
git-svn-id: svn+ssh://svn.fedorahosted.org/svn/pki/tags/DOGTAG_9_0_FEDORA_15_16_17_20111028@2278 c9f7a03b-bd48-0410-a16d-cbbf54688b0b
|