| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
The code for importing external cert into NSS database has been
moved into CertUtil.importExternalCert().
https://pagure.io/dogtagpki/issue/2280
Change-Id: Icb347943fc432ad97105229c14768822b070d99f
|
| |
|
|
|
|
|
|
|
| |
The code for importing certificate into NSS database has been
moved into CertUtil.importCert().
https://pagure.io/dogtagpki/issue/2280
Change-Id: I6a7a01b9170a5c0e9973ab1d5a7484349765dc5e
|
| |
|
|
|
|
|
|
|
| |
The OCSPProcessor has been modified to provide a default URL for
all requests submitted using the processor.
https://pagure.io/dogtagpki/issue/2652
Change-Id: I0175947d7d6a6a0284837e0d0464b139a5802444
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 server is modified to read the new OIDs in the PKIArchiveOptions
and handle them correctly.
Change-Id: I328df4d6588b3c2c26a387ab2e9ed742d36824d4
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is simpler to simply tell the client which
algorithm to use for key wrapping and encryption, rather
than use key sets. Therefore:
* KRAInfo and CAInfo are refactored to provide the
algorithms required for key wrapping and encryption.
* Client is modified to use these parameters to determine
which algorithms to use.
* We specify the OIDs that will be used in the PKIARchiveOptions
more correctly. The options are basically:
AES-128-CBC, DES3-CBC, AES KeyWrap/Pad
Change-Id: Ic3fca902bbc45f7f72bcd4676c994f8a89c3a409
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Switched out CrytoUtil calls that use DES and replaced them
with AES equivalents. Removed these now unneeded methods.
* Added 16 byte constant IV for AES operations. This must be
replaced by a randomly generated IV. Added TODOs where IVs
should be replaced.
* Corrected misspellings of "enreypted" in both request fields
and variable names
* Removed some code from null checks where the result could
never be null. These cases were flagged in eclipse as dead
code.
Change-Id: Iec0c0e86fd772af8b3c9588f11a0ea1e517776fb
|
| |
|
|
|
|
|
|
|
| |
The OCSPProcessor has been modified to log the OCSP response to
help troubleshooting.
https://pagure.io/dogtagpki/issue/2695
Change-Id: I9c880def083221af26cac902ff6d7852d0555a8f
|
| |
|
|
|
|
| |
proof
This patch implements the self-signed CMC requests, where the request is signed by the public key of the underlying request (PKCS#10 or CRMF). The scenario for when this method is used is when there was no existing signing cert for the user has been issued before, and once it is issued, it can be used to sign subsequent cert requests by the same user. The new enrollment profile introduced is : caFullCMCSelfSignedCert.cfg The new option introduced to both CRMFPopClient and PKCS10Client is "-y" which will add the required SubjectKeyIdentifier to the underlying request. When a CMC request is self-signed, no auditSubjectID is available until Identification Proof (v2) is verified, however, the cert subject DN is recorded in log as soon as it was available for additional information. Auditing is adjusted. More will come in the next couple CMC patches.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using an HSM, AES KeyWrapping is not available and so
some different code paths were exercised. Fixing bugs in those
paths uncovered a case where we were calling unwrapSymmetric()
with bits and not bytes for the key length.
This does not matter for 3DES, where JSS expects a length of 0,
but very much matters for AES. Fixing this - and the KeyClient
to actually use the returned wrapping algorithm to unwrap, allows
us now to return generated symmetric keys correctly.
Bugzilla BZ#1448521
Pagure: 2690
Change-Id: I2c5c87e28f6f36798b16de238bbaa21da90e7890
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the server cannot do key wrapping using the AES KeyWrap,
probably because the backend HSM cannot do key wrapping, then
there is a setting to allow it to use encrypt/decrypt instead.
If the key wrap algorithm is something simple like 3DES or AES-CBC,
then the client can just use key wrapping to wrap the key on its
token, and the server can use an encryption algorithm to decrypt.
The client does not need to know that the server cannot handle a
key wrap, because keywrapping and encryption are pretty much the
same mechanism - just either in server memory or not.
When we do key wrapping using AES KeyWrap though, there is no
corresponding encryption algorithm used to decrypt. So the server
cannot simply decrypt a message wrapped with AES Keywrap (or at least
not in any obvious way). So in this case, the client needs to know
if the server can handle keywrap.
The patch therefore does the following:
1. For CRMFPopClient, adds a command line option to specify if key
wrapping or encryption is required.
2. Reads an environment variable if no option is provided.
3. If encryption is specified, uses key wrapping using AES-CBC
which can be decrypted on the server side.
4. For cert-client, contacts the server to determine from the
CAInfoResource if keywrapping is supported.
Change-Id: If66f51c929cfde1c0ff3b9f39cb57b92fcdc150c
|
| |
|
|
| |
error checking and debugging
|
| |
|
|
| |
requests CMC encryptedPOP and decrypedPOP (Phase 1) also disable lraPOPwitness This patch implements the Proof of Possession for encryption only keys. This is a preliminary implementation with limitations. It does not support more than one request. ECC keys are untested. This version only uses default algorithms at some internal places. Not all limitations are listed here.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Refactor code in CryptoUtil to parametrize the algorithms used.
* Moved WrappingParams to utils jar to allow correct compilation.
* Removed code that created a PKIArchiveOptions structure from
CRMFPopClient and replaced with calls to CryptoUtil methods.
Note that the algorithms have been left as DES3. They will be
changed to AES in the next patch.
* Converted code in AuthorityKeyExportCLI to use the new methods
in CryptoUtil.
* Removed DRMTest this code is no longer maintained or used.
Change-Id: I8f625f0310877dca68f6a01285b6ff4e27e7f34a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Changed the client to use AES-128-CBC-PAD rather than DES-3.
Because AES-256-CBC-PAD has no OID defined, we use the following
hack:
* Pass in the AES-256-CBC OID as the encrypt algorithm OID
* Use PKCS#1.5 Padding.
* Changed the client to use AES for the wrapping key on retrieval.
* Changed the server to implicitly assume PKCS#1.5 (and a key size
of 128) when recieving the OID for AES.
* Changed the client to send, and the server to pass through
the encryption algorithm expected when retrieving the key.
* Fixed the generate_iv() function to generate an appropriately
sized IV on retrieval.
This code has been tested to successfully create and retrieve
secrets using AES. Ideally, we'd be using GCM rather than CBC,
which then requires no padding - and no hack needed. Hopefully,
we can get that working in a subsequent commit.
Change-Id: Ic9e8d50169be0fe357a48a5a1b1c452c7a3dfad0
|
| |
|
|
|
| |
The CryptoUtil.setSSLCiphers() has been modified to support a "-"
sign in front of the cipher name or ID to disable the cipher.
|
| |
|
|
|
| |
The CryptoUtil.setSSLCipher() has been modified to support ciphers
specified using hex ID.
|
| |
|
|
|
| |
A new parameter has been added to pki.conf to configure the SSL
ciphers used by PKI CLI in addition to the default ciphers.
|
| |
|
|
|
|
| |
The code that converts cipher name into cipher ID and enables
the cipher in CryptoUtil.setClientCiphers() has been moved into
a separate method.
|
| |
|
|
|
| |
The CryptoUtil.setClientCiphers() has been modified to throw
an exception on unsupported cipher.
|
| |
|
|
|
| |
The CryptoUtil.unsetSSLCiphers() has been modified not to ignore
exceptions.
|
| |
|
|
|
| |
The setClientCiphers() in CryptoUtil has been renamed to
setDefaultSSLCiphers() for clarity.
|
| |
|
|
|
| |
The CryptoUtil.setClientCiphers(String) has been reformatted to
simplify future refactoring.
|
| |
|
|
| |
rfc5272 (part 1)
|
| |
|
|
|
|
| |
This patch provides methods that can be shared between the CA and the ISharedToken plugins:
1. the convenience routines for quick encryption, decryption, hashing methods that take default algorithms.
2. The establishment of Issuance Protection Certificate
|
| |
|
|
|
| |
The CryptoUtil.setClientCiphers() has been reformatted to simplify
future refactoring.
|
| |
|
|
|
| |
The duplicate code for configuring default SSL version ranges has
been merged into reusable methods in CryptoUtil.
|
| |
|
|
| |
Change-Id: I6024ca5a32769b460d578dfad46598432381784c
|
| |
|
|
|
|
| |
Move some of the crypto functions in EncryptionUnit to CryptoUtil.
Change-Id: Iee391392fb88a87f6af3b450b69508fd52729a62
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The CryptoUtil has been modified to provide two separate methods
to obtain a token given the token name:
- getCryptoToken() returns crypto token
- getKeyStorageToken() returns key storage token
The getKeyStorageToken() was renamed from the existing
getTokenByName(). All codes using the old method have been updated
accordingly.
If the provided token name matches internal token name the methods
will return the corresponding internal crypto/key storage token.
The isInternalToken() was modified to check for empty string in
addition to the short and full name of the internal token.
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
|
| |
|
|
|
|
|
| |
Commit db58e6071f6bb57de006e6499c0a0c6a8c8e67bf has been reverted
due to build issue on RHEL/CentOS.
https://fedorahosted.org/pki/ticket/2531
|
| |
|
|
|
|
|
| |
The deprecated DefaultHttpClient in SubsystemClient, CRMFPopClient,
and OCSPProcessor has been replaced with HttpClientBuilder.
https://fedorahosted.org/pki/ticket/2531
|
| |
|
|
|
|
|
|
|
|
| |
The CryptoUtil.getTokenName() has been modified to check both the
short name and full name of the internal token.
The ConfigurationUtils.deleteCert() has also been modified to call
CryptoUtil.getTokenName().
https://fedorahosted.org/pki/ticket/2500
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To fix cloning issue in IPA the security_database.py has been
modified to import all certificates and keys in the PKCS #12 file
before the PKI server is started. Since the PKCS #12 generated by
IPA may not contain the certificate trust flags, the script will
also reset the trust flags on the imported certificates (i.e.
CT,C,C for CA certificate and u,u,Pu for audit certificate).
The ConfigurationUtils.restoreCertsFromP12() is now redundant and
it should be removed in the future, but for now it has been
modified to set the same trust flags on imported certificates.
The CryptoUtil.importCertificateChain() has also been modified to
set the same trust flags on imported certificates.
https://fedorahosted.org/pki/ticket/2424
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support to allow the TPS to do the following:
1. Request that the TKS creates a shared secret with the proper ID, pointing to the TPS.
2. Have the TKS securely return the shared secret back to the TPS during the end of configuration.
3. The TPS then imports the wrapped shared secret into it's own internal NSS db permanenty and.
4. Given a name that is mapped to the TPS's id string.
Additional fixes:
1. The TKS was modified to actually be able to use multiple shared secrets registered by
multiple TPS instances.
Caveat:
At this point if the same remote TPS instance is created over and over again, the TPS's user
in the TKS will accumulate "userCert" attributes, making the exportation of teh shared secret
not functional. At this point we need to assume that the TPS user has ONE "userCert" registered
at this time.
|
| |
|
|
|
|
| |
This patch removes references to the ciphers currently unsupported by NSS:
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
|
| |
|
|
| |
This patch adds support for SHA384withRSA signing algorithm.
|
| |
|
|
|
|
|
|
| |
The deployment tool has been modified to support adding Subordinate
CA extension into the CSR for Microsoft CA, and also adding generic
extensions to any system certificate.
https://fedorahosted.org/pki/ticket/2312
|
| |
|
|
|
|
|
|
| |
Add the method CryptoUtil.importPKIArchiveOptions for importing a
wrapped key from a PKIArchiveOptions object. Also add another
variant of the createPKIArchiveOptions method, with a narrower API.
Part of: https://fedorahosted.org/pki/ticket/1625
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The OCSP digest name lookup is currently defined in IOCSPAuthority
and implemented by OCSPAuthority, but /any/ code that deals with
CertID might need to know the digest, so move the lookup there.
Also refactor the lookup to use a HashMap, and add mappings for SHA2
algorithms.
|
| |
|
|
|
|
|
|
|
|
|
| |
PKCS #7 objects are being output with the "CERTIFICATE CHAIN" label
which is invalid (RFC 7468) and unrecognised by many programs
(including OpenSSL). Use the correct "PKCS7" label instead.
Also do a drive-by refactor of the normalizeCertAndReq to remove
some redundant code.
Fixes: https://fedorahosted.org/pki/ticket/1699
|
| |
|
|
|
|
|
|
| |
The LDAPPostReadControl can be used to read an entry after perfoming
an add, modify or modrdn, giving atomic access to operational
attributes.
Part of: https://fedorahosted.org/pki/ticket/1700
|
| | |
|
| |
|
|
| |
client and server This patch provides subsystem->subsystem cipher configuration when acting as a client
|
| |
|
|
| |
clients are: cli, HttpClient, and java console
|
| |
|
|
|
|
|
|
|
|
|
| |
The HttpConnection class has been modified to support fail-over
and timeout more consistently. The targets are parsed into a list
during initialization. All direct calls to HttpClient.connect()
are replaced with a method that will connect to the first available
target. All connections are now created with a timeout (which by
default is 0).
https://fedorahosted.org/pki/ticket/891
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds some new unit files and targets for starting instances
with nuxwdog, as well as logic within the pki-server nuxwdog module to
switch to/from the old and new systemd unit files.
It also corrects some issues found in additional testing of the nuxwdog
change scripts.
To use nuxwdog to start the instance, a user needs to do the following:
1. Create an instance normally.
2. Run: pki-server instance-nuxwdog-enable <instance_name>
3. Start the instance using:
systemctl start pki-tomcatd-nuxwdog@<instance_name>.service
To revert the instance, simply do the following:
1. Run: pki-server instance-nuxwdog-disable <instance_name>
2. Start the instance using:
systemctl start pki-tomcatd@<instance_name>.service
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is the first of several commits. This adds a LifecycleListener
to call init() on the nuxwdog client before any connectors or webapps
start up, and call sendEndInit() once initialization completes.
Code is also added to prompt for and test required passwords on startup.
All that is required to use nuxwdog is to start the server using nuxwdog.
An environment variable will be set that will trigger creation of the
NuxwdogPasswordStore. We expect tags for the required passwords to be in
cms.passwordList
|