| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
The Logger class has been modified to provide an interface to
create a Logger instance that stores the log category and log
source.
https://pagure.io/dogtagpki/issue/2689
Change-Id: I1dadcdf35af0f0a17e02328c73ef6d95ca691e7f
|
| |
|
|
|
|
|
|
|
| |
A LogSource enumeration has been added to replace the integer
log source in the Logger class.
https://pagure.io/dogtagpki/issue/2689
Change-Id: I6f69219fbbfa00d83f26a32174c75ff2782eb6af
|
| |
|
|
|
|
|
|
|
| |
A LogCategory enumeration has been added to replace the integer
log category in the Logger class.
https://pagure.io/dogtagpki/issue/2689
Change-Id: Ic92e64c3abdf859841eaf1006afc61bbf573086d
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First of all, the original CMC revocation only supports agent-signed CMC revocation requests from the UI where CMCRevReqServlet handles it with CMCAuth. It is in violation with https://tools.ietf.org/html/rfc5273 CMC Transport Protocols, as for HTTP/HTTPS, the body of the message is the binary value of the BER encoding of the PKI Request or Response,so HTML is not an approved method.The other way is through profileSubmitCMCFullServlet (or maybe not, as it was completely broken).
One thing that's much less crucial, but goes along with rfc update is the name of the revocation request ASN1 structure. In the new rfc5272, it is now called RevokeRequest insead of RevRequest.
This patch revamped the CMC revocation provision and fixing what's broken and adding what's missing.
On the client side:
CMCRequest
- Commented out the code where it made an assumption to use OtherMsg for the signer information. This makes no sense as the outer layer SignedData would have the same information when signing happens.
- removed the revRequest.nickname parameter from the configuration. From the code it seems like it expects the certificate to be revoked to exist in the user database, and it uses the same certificate to sign the revocation request. The RFC does allow for self-signed revocation, but it also allows for signing with another certificate provided that it has same subject. By removing the revRequest.nickname parameter, I am using the "nickname" parameter as the signer cert, which may or may not be the same certificate specified in revRequest.serial. It is less confusing. The change also eliminate the need for the cert to be revoked to be present in the db. In addition, revRequest.issuer only needs to be specified if revRequest.sharedSecret is used. The code will extract the issuer info from the signing cert.
- added support for unsigned data in support of shared secret in both CMCRequest and server; The original code assumed that a cmc revocation request that relies on shared secret still requires agent signing.
CMCRevoke
- The original code assumed that the nss db password is the same as Shared Secret (!!). This patch added a "-t" to accept shred secret, and keep the -p for the nss db password.
- The original code printed out b64 encoded request to the screen output as well as the file CMCRevoke.out. Both are unusable directly. This patch fixes it so that the output to the screen can be directly copied and pasted into the CMC revocate ui at ee (processed by CMCRevReqServlet); Again, this is not RFC conforming, but I fixed it anyways;
- The output to the file CMCRevoke.out has been fixed so that it is the BER encoding of the request, which can be fed directly into the updated server that now conforms to the RFC (see below)
- This code still requires the signer certificate nickname to run, making the shared secret method moot. Since CMCRequest has been updated to work properly, we can leave this for now.
On the server side.
CMCUserSignedAuth has been updated to handle unsigned DATA; Recall that the original CMC revocation only handled SIGNED_DATA (making assumption that agent always signs the requests). This addition is important to support shared secrets properly.
Another thing that's important change on the server side is that it now checks the revoking cert's subject against the signer's subject, if authenticated by CMCUserSignedAuth. The original code did not do that, I think it is because it always checks if it's an agent or not.
Something that could be improved on is to have its own servlet. However, due to the time restriction, I only updated existing EnrollProfile, ProfileSubmitCMCServlet, and CMCOutputTemplate to handle the rfc conforming cmc revocation requests.
The shared secret handling is left in the CMCOutputTemplate for now. Logically it would make sense to go into CMCUserSignedAuth. This could be left as a possible later ticket for improvement. Shared Token plugin implementation will be added in later ticket as well.
Previously missed signing cert validation is also added for more complete check.
Some SHA1 are turned into SHA2
Finally, some auditing are added, but it is not finalized. It will be done in the next ticket(s).
|
| |
|
|
|
|
|
| |
The CMS.getLogMessage() has been generalized to take an array of
Objects instead of Strings.
Change-Id: Ifcb96d47983a67961efa27325b8ae0a88d9e0231
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A new tcp.keepAlive parameter has been added for CS.cfg to
configure the TCP Keep-Alive option for all LDAP connections
created by PKI server. By default the option is enabled.
The LdapJssSSLSocketFactory has been modified to support both
plain and secure sockets. For clarity, the socket factory has been
renamed to PKISocketFactory.
All codes that create LDAP connections have been modified to use
PKISocketFactory such that the TCP Keep-Alive option can be applied
globally.
https://fedorahosted.org/pki/ticket/2564
|
| |
|
|
|
|
|
| |
To discourage the use of policy framework, the framework classes
have been moved into org.dogtagpki.legacy.
https://fedorahosted.org/pki/ticket/6
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
part 2 of: https://fedorahosted.org/pki/ticket/2298 [non-TMS] for key archival/recovery, not to record certain data in ldap and logs
This patch allows one to exclude certain ldap attributes from the enrollment records for crmf requests
(both CRMF, and CMC CRMF). The following are the highlights:
* CRMF Manual approval profile is disabled: caDualCert.cfg
- If excludedLdapAttrs.enabled is true, then this profile will not work, as the crmf requests (by default it is false)
are not written to ldap record for agents to act on
* excludedLdapAttrs.attrs can be used to configure the attribute list to be excluded
* a new CRMF "auto approval" (directory based, needs to be setup) is provided
* if excludedLdapAttrs.enabled is true (in both ca and kra), the following fields are not written to the ldap record in case of CRMF:
(note: the code deliberately use literal strings on purpose for the reason that the exact literal strings need to be spelled out
in excludedLdapAttrs.attrs if the admin chooses to override the default)
"req_x509info",
"publickey",
"req_extensions",
"cert_request",
"req_archive_options",
"req_key"
* Because of the above (possible exclusion of cert requests in record, profiles
that require agent manual approval will no longer function in the case that
excludedLdapAttrs.enabled is true
* a sleepOneMinute() method is added for debugging purpose. It is not called in the final code, but is left there for future debugging purpose
* code was fixed so that in KRA request will display subject name even though the x509info is missing from request
* cmc requests did not have request type in records, so they had to be added for differentiation
The following have been tested:
* CRMF auto enroll
* CRMF manual enroll/approval
* CMC-CRMF enroll
* both CA and KRA internal ldap are examined for correct data exclusion
Note: CRMF could potentially not include key archival option, however, I am not going to differentiate them at the moment. An earlier prototype I had built attempted to do that and the signing cert's record isn't excluded for attrs write while it's CRMF request is the same as that of its encryption cert counterpart within the same request. Due to this factor (multiple cert reqs with the same request blob), I am treating them the same for exclusion.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The TPS VLVs for tokens and activities has been modified to sort
the results by date in reverse order.
The DBRegistry.getLDAPAttributes() was modified to support reverse
sort order by recognizing the "-" prefix in the list of sort keys
and pass it to LDAP.
The DBVirtualList.setSortKey() was modified to ignore bubble up the
exceptions that happen during LDAP attribute mapping.
https://fedorahosted.org/pki/ticket/2263
https://fedorahosted.org/pki/ticket/2269
|
| |
|
|
|
|
|
| |
With this fix, error messages are returned to the user when
a request is rejected - either in the UI or from the pki CLI.
Trac Ticket 1247 (amongst others)
|
| |
|
|
| |
Part of Trac Ticket #2041
|
| |
|
|
|
|
| |
This patch implements the TPS operation auditing: TOKEN_APPLET_UPGRADE_SUCCESS,TOKEN_APPLET_UPGRADE_FAILURE,TOKEN_CERT_ENROLLMENT,TOKEN_CERT_RENEWAL,TOKEN_CERT_RETRIEVAL,TOKEN_KEY_RECOVERY,TOKEN_CERT_STATUS_CHANGE_REQUEST,TOKEN_OP_REQUEST,TOKEN_FORMAT_SUCCESS,TOKEN_FORMAT_FAILURE,TOKEN_KEY_CHANGEOVER,TOKEN_KEY_CHANGEOVER_FAILURE,TOKEN_PIN_RESET_SUCCESS,TOKEN_PIN_RESET_FAILURE,TOKEN_STATE_CHANGE,TOKEN_AUTH_SUCCESS,TOKEN_AUTH_FAILURE
Administrative auditing (via REST interface) will be covered in a separate ticket
|
| |
|
|
|
|
|
|
| |
The selftest has been modified to throw an exception and provide
more specific error message if a test fails in order to help
troubleshoot the problem.
https://fedorahosted.org/pki/ticket/1328
|
| |
|
|
| |
client and server This patch provides subsystem->subsystem cipher configuration when acting as a client
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an interim solution for supporting HSM failover by automatically
shutting down the server when signing key becomes inaccessible.
At auto-shutdown, a crumb fiile will be left in the instance directory
for an external daemon to detect and restart, if necessary.
Due to limitation of the watch dog (nuxwdog) at present time,
the restart option currently only works if started with watch dog (nuxwdog),
and it will prompt for passwords on the terminals.
The restart counter is to prevent the server from going into an infinite restart
loop. Administrator will have to reset autoShutdown.restart.count to 0 when max
is reached.
(cherry picked from commit 5a9ecad9172f76ca1b94b40aedcdd49d009aceb1)
|
| |
|
|
|
|
|
|
| |
Various codes have been modified to properly stop threads during
shutdown. A new ID attribute has been added to the LDAP connection
factory classes to help identify leaking threads.
https://fedorahosted.org/pki/ticket/1327
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The CA installation process requires starting with the profile
subsystem disabled, then enabling it once profiles have been loaded
into the database. Accordingly, to avoid hacks with hardcoded
offsets, add the "enabled" CS.cfg configuration parameter along with
methods to enable or disable a subsystem based on the subsystem ID.
A disabled subsystem does not have its `init` method called, but it
is still instantiated and added to the registry so that other code
can look up a subsystem by name and find out its class.
Subsystems are enabled by default.
This commit also removes an assumption that the subsystem config
sub-store names are sequential numbers beginning at `0`.
|
| |
|
|
| |
subsystem
|
|
|
The test classes have been moved from base/common/test to base/server/test
and into the cmscore package because they are dependent on server classes.
|
