| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch supports CMC-based system certificate requests.
This patch contains the following:
* The code in CMCAuth (agent-based) to check ssl client auth cert against the CMC signing cert
* The cmc-based system enrollment profiles:
caCMCauditSigningCert.cfg
caCMCcaCert.cfg
caCMCkraStorageCert.cfg
caCMCkraTransportCert.cfg
caCMCocspCert.cfg
caCMCserverCert.cfg
caCMCsubsystemCert.cfg
* new URI's in web.xml as new access points
Usage example can be found here:
http://pki.fedoraproject.org/wiki/PKI_10.4_CMC_Feature_Update_(RFC5272)#Examples_.28System_Certificates.29
|
| |
|
|
|
|
|
|
|
| |
Duplicate log() methods for audit events have been merged into the
Logger class.
https://pagure.io/dogtagpki/issue/2689
Change-Id: I7a5147ff3221a52a82e69f56faf2156c04256db2
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Signed audit logger creation has been simplified into:
Logger signedAuditLogger = SignedAuditLogger.getLogger();
The null checks on signed audit logger have been removed since
it cannot be null. Audit messages can be logged as follows:
signedAuditLogger.log(message);
https://pagure.io/dogtagpki/issue/2689
Change-Id: I3bf781b0194a6cbb166f71751c098d1c2a3a657a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
| |
New audit(AuditEvent) methods have been added alongside the
existing audit(String) methods.
Change-Id: Ia02a7daa8b9e8693208fe34309d8d727cc32ce54
|
| |
|
|
| |
Change-Id: I3eb97554a1d0f4b86c981692ab0130b28c9c5288
|
| |
|
|
|
| |
To help troubleshooting the CMCAuth has been modified to log a
message when the CMC is missing.
|
| |
|
|
|
|
|
|
|
| |
Direct invocations of CryptoManager.getTokenByName() have been
replaced with CryptoUtil.getCryptoToken() and getKeyStorageToken()
to ensure that internal token names are handled consistently both
in normal mode and FIPS mode.
https://fedorahosted.org/pki/ticket/2556
|
| |
|
|
|
|
|
|
| |
The codes that detect internal token name have been modified to
use CryptoUtil.isInternalToken() such that the comparison can be
done consistently both in normal mode and FIPS mode.
https://fedorahosted.org/pki/ticket/2556
|
| |
|
|
|
|
|
| |
The internal token short name literals have been replaced with
CryptoUtil.INTERNAL_TOKEN_NAME.
https://fedorahosted.org/pki/ticket/2556
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 tomcat, cms, and cmscore packages have been moved from base/common
into separate folders in base/server so that they can be built separately.
|
