summaryrefslogtreecommitdiffstats
path: root/base/common/src/com/netscape/cms/servlet/csadmin
Commit message (Collapse)AuthorAgeFilesLines
* Set paths for default instanceAde Lee2012-11-041-0/+19
| | | | | | | | | | | | | | With this patch, it will be possible to install a default instance simply by adding the passwords in the pkideployment.cfg. This file can then be used without additional alteration to add subsystems to the same instance, by re-running pkispawn against the config file. The patch makes sure that cert nicknames, database and baseDN , admin users and client db are unique per subsystem. An option is added to reuse the existing server cert generated by the first subsystem and copy the required data to all subsystems. Ticket 379, 385
* Refactored GetDomainXML servlet.Endi Sukma Dewata2012-10-261-119/+10
| | | | | | | The GetDomainXML servlet has been refactored to use the new SecurityDomainProcessor. Ticket #309
* Added REST interface to get domain info.Endi Sukma Dewata2012-10-263-9/+291
| | | | | | | | The REST interface for security domain has been updated to provide a method to get the domain info. A CLI has been provided to access this method. Ticket #309
* Provide option to install, rather than replicate schema in a cloneAde Lee2012-10-223-4/+39
|
* Reorder VLV indexing for clones to avoid errorsAde Lee2012-10-223-12/+11
|
* Added PKIConnection.Endi Sukma Dewata2012-10-181-8/+6
| | | | | | | | | The code in PKIClient has been refactored into PKIConnection such that a single connection object can be used by several REST clients. The PKIClient will remain the base class for all REST clients. Ticket #357
* Refactored GetCookie servlet.Endi Sukma Dewata2012-10-181-89/+43
| | | | | | | The GetCookie servlet has been refactored to use the new SecurityDomainProcessor. Ticket #309
* Enabled authentication for security domain REST interface.Endi Sukma Dewata2012-10-184-41/+162
| | | | | | | | The REST interface for security domain has been refactored and configured such that it requires authentication. A CLI has been added to get an installation token. Ticket #309
* Reverted to old interface and httpclient to get installation token.Ade Lee2012-10-121-0/+22
| | | | | This is a workaround until we can get the new interface working on IPA clones.
* Added version number into server status.Endi Sukma Dewata2012-09-281-0/+2
| | | | | | | The GetStatus servlet has been modified to include the server version number. Ticket #339
* fall back to old interface for installtoken if neededAde Lee2012-09-271-3/+71
|
* Renamed escapeDN() into escapeRDNValue().Endi Sukma Dewata2012-09-271-16/+16
| | | | | | | The escapeDN() has been renamed into escapeRDNValue() for better clarity. Ticket #193
* Use getStatus servlet to provide startup statusAde Lee2012-09-211-0/+2
| | | | Ticket 314
* Changes to use standard dbuserAde Lee2012-09-193-26/+48
| | | | | | | | | | | | | | | | | We create a user that can be used to connect to the database using the subsystem cert for client auth. We identified this user, using the seeAlso attribute and provided certmap rules to this effect. For this user, we used to reuse the uid = user CA-hostname-port, which is already created for inter-system communication. But this is problematic if more than one dbuser exists, as the directory server may bind as the incorrect user. In any replication topology, there must be only one dbuser using the subsystem cert. To simplify things, we create a new user specifically for this purpose (pkidbuser), and we remove the seeAlso attribute from the older dbusers. A script is needed to convert existing dogtag 9 istances to use the new user, and set the relevant acls. This will be done in a separate commit.
* Added DN and filter escaping in ConfigurationUtils.Endi Sukma Dewata2012-09-191-19/+19
| | | | | | | The ConfigurationUtils has been modified to escape values used in DN or filter according to LDAP standard. Ticket #193
* Various fixes to installation servlet and pki-deployAde Lee2012-09-121-1/+4
| | | | | | | Added logging so that we can see what is passed in to server from pkispawn. Fixed incorrect dbuser specification. Added required replication config items to pkispawn. Initial refactoring of construct_pki_configuration_data in pkijython.py
* Fixed conflicting LDIF files.Endi Sukma Dewata2012-09-041-3/+6
| | | | | | | | | During subsystem configuration the ConfigurationUtils.importLDIFS() would generate LDIF files in <instance>/conf folder which may conflict with files belonging to other subsystems. The code has been modified to generate the files in <instance>/<subsystem>/conf folder. Ticket #89
* Moved REST CLI into pki-tools.Endi Sukma Dewata2012-08-291-2/+2
| | | | | | | | | | The pki-client.jar has been split and merged into pki-certsrv.jar and pki-tools.jar. The REST client classes are now packaged in com.netscape.certsrv.<component> packages. The REST CLI classes are now packaged in com.netscape.cmstools.<component> packages. The "pki" script has been moved into pki-tools RPM package. Ticket #215
* subsequent OCSPs and DRM connector protectionAndrew Wnuk2012-08-203-50/+60
| | | | | | | | | This patch corrects process of attaching OCSP subsystem to CA. It improves handling of adding subsequent OCSP subsystems to CA. This patch also prevents DRM connector to be overwritten by subsequent DRM installations. Bug 804179.
* PKI Deployment ScriptletsMatthew Harmsen2012-08-179-19/+34
| | | | | | | | | | | * TRAC Ticket #266 - for non-master CA subsystems, pkidestroy needs to contact the security domain to update the domain * Made Fedora 17 rely upon tomcatjss 7.0.0 or later * Changed Dogtag 10 build-time and runtime requirements for 'pki-deploy' * Altered PKI Package Dependency Chain (top-to-bottom): pki-ca, pki-kra, pki-ocsp, pki-tks --> pki-deploy --> pki-common * Changed TPS to require a build-time dependency of 'httpd-devel >= 2.4.2' * Clarified RPM build script's usage message
* Ticket 219 - Conversion of integer variable to BigIntegerAbhishek Koneru2012-08-171-4/+2
|
* Fixed REST common class dependency.Endi Sukma Dewata2012-08-152-2/+49
| | | | | | | | | The ConfigurationResponse previously has a method that uses a class that exists on the server only, creating a dependency issue since the ConfigurationResponse will be used by the client as well. The method now has been moved into a separate factory class. Ticket #259
* Reorganized REST common classes.Endi Sukma Dewata2012-08-1511-1584/+10
| | | | | | | The common classes used by REST client and services have been moved into the com.netscape.certsrv.<component> packages. Ticket #215
* Reorganized REST client classes.Endi Sukma Dewata2012-08-154-418/+2
| | | | | | | The REST client classes have been moved into the com.netscape.cms.client.<component> packages. Ticket #215
* Cleaned up REST common class names.Endi Sukma Dewata2012-08-157-155/+156
| | | | | | | The REST common classes have been renamed for better clarity and consistency. Ticket #259
* Cleaned up REST server class names.Endi Sukma Dewata2012-08-151-3/+3
| | | | | | | The REST server classes have been renamed for better clarity and consistency. Ticket #259
* Cleaned up REST client class names.Endi Sukma Dewata2012-08-155-72/+7
| | | | | | | The REST client classes have been renamed for better clarity and consistency. Ticket #259
* Moved REST services into separate URLs.Endi Sukma Dewata2012-08-033-16/+14
| | | | | | | | | | | To support different access control configurations the REST services have been separated by roles. Services that don't need authentication will be available under /rest. Services that require agent rights will be available under /rest/agent. Services that require admin rights will be available under /rest/admin. Ticket #107
* PKI Deployment ScriptletsMatthew Harmsen2012-08-022-2/+6
| | | | | | | | | * PKI TRAC Ticket #279 - Dogtag 10: Fix remaining 'cloning' issues in 'pkispawn' . . . * PKI TRAC Ticket #280 - Dogtag 10: Fix remaining issues in 'pkidestroy' related to deletion of more than one instance . . . * PKI TRAC Ticket #281 - Dogtag 10: Fix 'pkidaemon'/'operations' issue to handle individual instance . . .
* selinux policy changes to use standard portsAde Lee2012-07-311-1/+1
| | | | | | | Selinux policy has been changed to use standard tomcat ports. Corresponding changes have been made in the pki-deploy scripts. Minor change in config script for password check.
* Added support for basic authentication.Endi Sukma Dewata2012-07-301-15/+116
| | | | | | | | | | | | | | The CMSRestClient has been modified to support basic authentication and handle HTTP redirection. The basic authentication can be used as follows: pki -U <server uri> -u <username> -w <password> user-find Some protected REST services might require secure connection. If the user tries to call these services over HTTP the CLI will handle the redirection automatically to an HTTPS port. Ticket #107
* Added ClientConfig.Endi Sukma Dewata2012-07-303-23/+24
| | | | | | | | A new ClientConfig class has been added to encapsulate client configuration parameters. These parameters include server URI, certificate database, certificate nickname, and password. Ticket #107
* PKI Deployment ScriptletsMatthew Harmsen2012-07-191-1/+3
| | | | | | | | | | | | | | | | | | | | * Integration of Tomcat 7 * Introduction of dependency upon tomcatjss 7.0 * Removal of http filtering configuration mechanisms * Introduction of additional slot substitution to support revised filesystem layout * Addition of 'pkiuser' uid:gid creation methods * Inclusion of per instance '*.profile' files * Introduction of configurable 'configurationRoot' parameter * Introduction of default configuration of 'log4j' mechanism (alee) * Modify web.xml to use new Application classes to bootstrap servers (alee) * Introduction of "Wrapper" logic to support Tomcat 6 --> Tomcat 7 API change (jmagne) * Added jython helper function to allow attaching a remote java debugger (e. g. - eclipse)
* Additional checks to avoid null pointers in Installation servletAde Lee2012-07-171-1/+5
|
* Fixed client cert authentication problem.Endi Sukma Dewata2012-07-121-28/+13
| | | | | | | The CertRestClient has been fixed to pass the client certificate nickname to the CMSRestClient class to configure the SSLSocket properly. Ticket #161
* Refactored ConfigurationRESTClient.Endi Sukma Dewata2012-07-121-151/+4
| | | | | | | The ConfigurationRESTClient has been modified to extend CMSRestClient to address error handling issue in ConfigurationTest. Ticket #218
* Added cert revocation CLI.Endi Sukma Dewata2012-07-111-2/+30
| | | | | | The cert revocation CLI provides a tool to revoke and unrevoke certificates. Ticket #161
* Added REST error handler.Endi Sukma Dewata2012-06-271-0/+22
| | | | | | | A new getEntity() method has been added to obtain the entity from a Response object and also map HTTP errors into exceptions. Ticket #161
* Fixes for NULL_RETURNS Coverity Issues - Part 2Abhishek Koneru2012-06-141-3/+11
|
* Added user CLI.Endi Sukma Dewata2012-05-312-19/+15
| | | | | | The user CLI provides a tool to manage users and user certificates. Ticket #160
* Provide CA EE Restful interface and test client.Jack Magne2012-05-073-1/+238
| | | | | | | | | | | | | | | | | | Tickets #144 and #145 Providing the following: 1. Simple EE restful interface for certificates, printing, listing and searching. 2. Simple EE restful interface for certificate enrollment requests. 3. Simple EE restful interface for profiles and profile properties. 4. Simple Test client to exercise the functionality. 5. Created restful client base class inherited by CARestClient and DRMRestClient. 6. Provide simple restful implementations of new interfaces added. ToDO: Need some more refactoring to base classes for some of the new classes which are similar to classes in the DRM restful area. ToDO: Actual certificate enrollment code that will be refactored from existing ProfileSubmitServlet. Provide CA EE Restful interface and test client review fixes.
* BZ 819111 - non existent container ou=cmsusers breaks replicationAde Lee2012-05-071-1/+21
| | | | Added code to create container on master if it does not exist.
* Removed obsolete installation servletsAde Lee2012-05-0219-2687/+39
|
* Refactor installation servlets to use common code in ConfigurationUtilsAde Lee2012-05-0219-5604/+771
| | | | Ticket #156
* RESTful servlet to configure system in a single servlet.Ade Lee2012-05-0115-3/+6249
| | | | | | | | | | | | | Installation code common to the panels and the installation servlet are extracted to a ConfigurationUtils file. The panel code will be cleaned up to use the code in this class in a later commit. Contains restful client and test driver code. The test driver code should be modified and placed in a junit/system test framework. Installation has been tested to work with the following installations: master CA, clone CA, KRA, OCSP, TKS, subordinate CA, CA signed by external CA (parts 1 and 2). Ticket #155
* Removed unused private fields.Endi Sukma Dewata2012-04-1216-19/+3
| | | | | | | Most of unused private fields have been removed because they generate warnings in Eclipse. Some are kept because it might be useful later. Ticket #139
* Removed unnecessary type casts.Endi Sukma Dewata2012-04-098-13/+13
| | | | | | Unnecessary type casts have been removed using Eclipse Quick Fix. Ticket #134
* Removed whitespaces from Java code.Endi Sukma Dewata2012-04-0931-52/+52
| | | | | | | | Whitespaces in Java code have been removed with the following command: find . -not -path .git -name *.java -exec sed -i 's/[[:blank:]]\+$//' {} \; Ticket #134
* Ignored VelocityServlet deprecation warnings.Endi Sukma Dewata2012-04-092-0/+2
| | | | | | | The VelocityServlet is deprecated but the replacement is not available in Fedora, so the warnings are ignored for now. Ticket #133
* Fix for Bug 745278 - [RFE] ECC encryption keys cannot be archived.Christina Fu2012-04-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)