summaryrefslogtreecommitdiffstats
path: root/base/util
Commit message (Collapse)AuthorAgeFilesLines
* Refactored CertUtil.importExternalCert().Endi S. Dewata2017-07-051-31/+39
| | | | | | | | | The code for importing external cert into NSS database has been moved into CertUtil.importExternalCert(). https://pagure.io/dogtagpki/issue/2280 Change-Id: Icb347943fc432ad97105229c14768822b070d99f
* Refactored CertUtil.importCert().Endi S. Dewata2017-07-051-7/+6
| | | | | | | | | The code for importing certificate into NSS database has been moved into CertUtil.importCert(). https://pagure.io/dogtagpki/issue/2280 Change-Id: I6a7a01b9170a5c0e9973ab1d5a7484349765dc5e
* Fix 3DES archivalAde Lee2017-06-161-8/+15
| | | | | | | | | | | | A previous commit mistakenly conflated the wrapping parameters for DES and DES3 cases, resulting in incorrect data being stored if the storage was successful at all. This broke ipa vault and probably also token key archival and recovery. This patch sets the right parameters for the 3DES case again. Part of BZ# 1458043 Change-Id: Iae884715a0f510a4d492d64fac3d82cb8100deb4
* Fix regression in pkcs12 key bag creationFraser Tweedale2017-06-161-21/+37
| | | | | | | | | | | | | | | | | Commit 633c7c6519c925af7e3700adff29961d72435c7f changed the PKCS #12 file handing to never deal with raw private key material. PKCS12Util.addKeyBag() was changed to export the PrivateKey handle, or fail. This change missed this case where a PKCS #12 file is loaded from file, possibly modified, then written back to a file, without involving an NSSDB. One example is pkcs12-cert-del which deletes a certificate and associated key from a PKCS #12 file. Fix the PKCS12Util.addKeyBag() method to use the stored EncryptedPricateKeyInfo if available, otherwise export the PrivateKey handle. Fixes: https://pagure.io/dogtagpki/issue/2741 Change-Id: Ib8098126bc5a79b5dae19103e25b270e2f10ab5a
* Added default URL for OCSPProcessor.Endi S. Dewata2017-06-151-0/+13
| | | | | | | | | 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
* Ticket #2619 Allow CA to process user-signed CMC revocation requestsChristina Fu2017-06-081-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* Server side changes to correctly parse the new PKIArchiveOptionsAde Lee2017-06-072-7/+82
| | | | | | | The server is modified to read the new OIDs in the PKIArchiveOptions and handle them correctly. Change-Id: I328df4d6588b3c2c26a387ab2e9ed742d36824d4
* Refactor client to not use keysetsAde Lee2017-06-071-0/+22
| | | | | | | | | | | | | | | | | | 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
* Convert CMC code to use AESAde Lee2017-05-311-77/+7
| | | | | | | | | | | | | | | * 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
* Updated log messages in OCSPProcessor.Endi S. Dewata2017-05-231-3/+11
| | | | | | | | | The OCSPProcessor has been modified to log the OCSP response to help troubleshooting. https://pagure.io/dogtagpki/issue/2695 Change-Id: I9c880def083221af26cac902ff6d7852d0555a8f
* Tocket2673- CMC: allow enrollment key signed (self-signed) CMC with identity ↵Christina Fu2017-05-173-14/+200
| | | | | | 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.
* Fix symmetic key retrieval in HSMAde Lee2017-05-061-2/+2
| | | | | | | | | | | | | | | | | 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
* PKCS12Util: add some much-needed commentsFraser Tweedale2017-04-292-0/+36
| | | | | | | Part of: https://pagure.io/dogtagpki/issue/2610 Change-Id: Ic35a81c4c4dd49622bfdeb677d588641594b7ec6 (cherry picked from commit 507908d1aac8f9db6c380f5cae634521608043e8)
* PKCS12Util: use AES to encrypt private keysFraser Tweedale2017-04-292-88/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update PKCS12Util to use AES-256-CBC to encrypt private keys. Use JSS CryptoStore methods to ensure that all key wrapping and unwrapping is done on the token. Specifically, CryptoStore.getEncryptedPrivateKeyInfo replaces the previous process where a symmetric key was generated, the private key wrapped to the symmetric key, then decryted into Dogtag's memory, then re-encrypted under the supplied passphrase. Now the key gets wrapped directly to the supplied passphrase. Similarly, for import, the EncryptedPrivateKeyInfo was decrypted using the supplied passphrase, then encrypted to a freshly generated symmetric key, which was then used to unwrap the key into the token. Now, the new JSS method CryptoStore.importEncryptedPrivateKeyInfo is used to unwrap the EncryptedPrivateKeyInfo directly into the token, using the supplied passphrase. As a result, the PKCS12KeyInfo class, which previously stored unencrypted key material (a PrivateKeyInfo object), it now only deals with PrivateKey (an opaque handle to an PKCS #11 object) on export and encoded (byte[]) EncryptedPrivateKeyInfo data on import. This split suggests that PKCS12KeyInfo should be decomposed into two classes - one containing a PrivateKey and the other containing a byte[] encryptedPrivateKeyInfo - but this refactoring is left for another day. Part of: https://pagure.io/dogtagpki/issue/2610 Change-Id: I75d48de4d7040c9fb3a9a6d1e920c191aa757b70 (cherry picked from commit 2e198ddbe9ec5000ee7e14df0aa364b600d3aa92)
* Modified CRMFPopClient to use correct wrapping for encrypt caseAde Lee2017-04-121-14/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix generation of CRMF request for ECC keysAde Lee2017-04-031-1/+10
| | | | | | | | | | | Old CRMFPopClients add the OID for ECC public keys in the encryption algorithm OID for no obvious reason (considering the OID was never read on the server side to begin with). Now that we do read and use that field, we need to set it properly, and also special case on the server side to handle old clients. Change-Id: I0d753e572206e9062746c879ce683978e5e657bd
* Fix retrieval for symmetric keysAde Lee2017-03-281-0/+18
| | | | | | | | | | | | | Up to now, we have only ever used the same algorithm (DES3_CBC) for key wrapping and encryption. With the change to use AES Keywrap and AES CBC, we need to know which mechanism was used to encrypt/wrap the secrets when returned to the client. This means passing back more information to the client with the key data, and also modifying the client to use this information to decode the data correctly. Change-Id: I7232085c1eedf38c63abad81db08acc912fa1da1
* Bug #2615 CMC: cleanup code for Encrypted Decrypted POP This patch adds more ↵Christina Fu2017-03-281-0/+18
| | | | error checking and debugging
* Bug 1419742: CMC RFE: provide Proof of Possession for encryption cert ↵Christina Fu2017-03-281-1/+69
| | | | 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.
* Change CRMFPopClient to use AES-KeyWrap with paddingAde Lee2017-03-241-21/+30
| | | | | | | | | | | | | | | | | | Also made a couple of small changes to WrappingParams. * Set the wrapIV to null when AES KeyWrap is used. Trying to unpack the PKIArchiveOptions package with this IV set to null fails. * removed superfluous this modifiers. Added a parameter KEY_WRAP_PARAMETER_SET which is set in /etc/pki/pki.conf. If this parameter is set to 0, we will use the old DES3 algorithms. This can be set by clients talking to old servers. CRMFPopClient has the ability to automatically submit requests to a CA. In this case, we shouldcontact the server and determine the version using InfoClient, and choose the algorithm accordingly. We will implement this in a separate patch. Change-Id: Ib4a99545cb59b62a96c272311595e96dda10979e
* Refactor code that creates PKIArchiveOptions objectsAde Lee2017-03-232-48/+328
| | | | | | | | | | | | | | * 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
* Fix Java client to use AESAde Lee2017-03-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | * 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
* Added support for disabling SSL ciphers in pki.conf.Endi S. Dewata2017-03-211-1/+8
| | | | | The CryptoUtil.setSSLCiphers() has been modified to support a "-" sign in front of the cipher name or ID to disable the cipher.
* Added support for hex cipher IDs in pki.conf.Endi S. Dewata2017-03-211-3/+9
| | | | | The CryptoUtil.setSSLCipher() has been modified to support ciphers specified using hex ID.
* Added pki.conf parameter for SSL ciphers.Endi S. Dewata2017-03-191-0/+12
| | | | | A new parameter has been added to pki.conf to configure the SSL ciphers used by PKI CLI in addition to the default ciphers.
* Refactored CryptoUtil.setClientCiphers().Endi S. Dewata2017-03-191-6/+11
| | | | | | The code that converts cipher name into cipher ID and enables the cipher in CryptoUtil.setClientCiphers() has been moved into a separate method.
* Fixed error handling in CryptoUtil.setClientCiphers().Endi S. Dewata2017-03-191-1/+3
| | | | | The CryptoUtil.setClientCiphers() has been modified to throw an exception on unsupported cipher.
* Fixed error handling in CryptoUtil.unsetSSLCiphers().Endi S. Dewata2017-03-191-7/+7
| | | | | The CryptoUtil.unsetSSLCiphers() has been modified not to ignore exceptions.
* Renamed CryptoUtil.setClientCiphers().Endi S. Dewata2017-03-191-2/+2
| | | | | The setClientCiphers() in CryptoUtil has been renamed to setDefaultSSLCiphers() for clarity.
* Cleaned up CryptoUtil.setClientCiphers(String).Endi S. Dewata2017-03-181-24/+17
| | | | | The CryptoUtil.setClientCiphers(String) has been reformatted to simplify future refactoring.
* pagure#2605 (add one missing method) CMC feature: id-cmc-identityProofV2 per ↵Christina Fu2017-03-171-0/+5
| | | | rfc5272 (part 1)
* pagure#2605 CMC feature: id-cmc-identityProofV2 per rfc5272 (part 1)Christina Fu2017-03-171-0/+145
| | | | | | 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
* Cleaned up CryptoUtil.setClientCiphers().Endi S. Dewata2017-03-171-19/+23
| | | | | The CryptoUtil.setClientCiphers() has been reformatted to simplify future refactoring.
* Removed duplicate code to configure SSL version ranges.Endi S. Dewata2017-03-171-0/+24
| | | | | The duplicate code for configuring default SSL version ranges has been merged into reusable methods in CryptoUtil.
* Continue to move more crypto into CryptoUtilAde Lee2017-03-141-12/+48
| | | | Change-Id: I6024ca5a32769b460d578dfad46598432381784c
* Refactor crypto codeAde Lee2017-03-142-111/+86
| | | | | | Move some of the crypto functions in EncryptionUnit to CryptoUtil. Change-Id: Iee391392fb88a87f6af3b450b69508fd52729a62
* X500Name: add method to get all attributes of a given typeFraser Tweedale2017-02-081-0/+21
| | | | | | | | | | | | | | To implement a profile default that copies the CN to a SAN dNSName, we need to examine the CN values present in the Subject DN. Specifically, we want to look at the "most specific" CN value. The 'getCommonName' method returns the "least specific" value in the name, thus is not suitable. Add the 'getAttributesForOid(ObjectIdentifier)' method, which returns an ordered list of values of the given name attribute type, from least specific to most specific. Part of: https://fedorahosted.org/pki/ticket/1710
* SubjectAlternativeNameExtension: add GeneralNames getter/setterFraser Tweedale2017-02-081-0/+15
| | | | | | | | | | | | To implement a profile default that copies CN to SAN dNSName, we need to read and set the 'GeneralNames' of the extension. This can be done via the 'get' and 'set' methods but this interface is awkward and requires the caller to deal with exceptions that aren't fundamental to the get/set actions. Add the 'setGeneralNames' and 'getGeneralNames' methods. Part of: https://fedorahosted.org/pki/ticket/1710
* GeneralName: add method to get at inner valueFraser Tweedale2017-02-081-0/+15
| | | | | | | | | | | | | | | | | | The 'GeneralNameInterface' interface represents a single X.509 General Name value. Various types are supported. The 'GeneralName' class (which also implements 'GeneralNameInterface') is a singleton container for another 'GeneralNameInterface' value. To implement a profile component that copies CN to a SAN dNSName, we need to examine existing General Names in the SAN extension (if present), to avoid duplicate values. We can iterate 'GeneralNames', but if the value is of type 'GeneralName' we need a way to "unwrap" the value, down to the innermost value which will be of a specific General Name type. Add the 'unwrap' method to 'GeneralName'. Part of: https://fedorahosted.org/pki/ticket/1710
* DNSName: add method to get valueFraser Tweedale2017-02-081-0/+8
| | | | | | | | To implement a profile default that copies CN to SAN dNSName, we need to examine existing dNSName values. To support this, add the 'getValue()' method to 'DNSName'. Part of: https://fedorahosted.org/pki/ticket/1710
* Ticket #1741 ECDSA certs Alg IDs contian parameter fieldChristina Fu2017-01-261-9/+32
| | | | | | Per rfc5758, When the ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384, or ecdsa-with-SHA512 algorithm identifier appears in the algorithm field as an AlgorithmIdentifier, the encoding MUST omit the parameters field. Note: Since we do not support DSA, this patch does not attempt to address them. Also, while we do not claim to support sha224, the patch adds enough code to process the OID just for completeness. However, it does not attempt to offer it as part of the signing algorithms.
* Updated CryptoUtil.Endi S. Dewata2017-01-261-7/+25
| | | | | | | | | | | | | | | | | | | 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
* Replaced internal token short name literals.Endi S. Dewata2017-01-241-1/+2
| | | | | | | The internal token short name literals have been replaced with CryptoUtil.INTERNAL_TOKEN_NAME. https://fedorahosted.org/pki/ticket/2556
* Revert "Replaced deprecated DefaultHttpClient."Endi S. Dewata2016-12-021-3/+7
| | | | | | | Commit db58e6071f6bb57de006e6499c0a0c6a8c8e67bf has been reverted due to build issue on RHEL/CentOS. https://fedorahosted.org/pki/ticket/2531
* Update PKCS12Util to use SLF4J.Endi S. Dewata2016-11-182-25/+27
| | | | | | | | | The PKCS12Util class has been modified to use SLF4J logging framework. The CMake scripts has been modified to include SLF4J libraries in the classpath. The spec file has been modified to add SLF4J dependencies. https://fedorahosted.org/pki/ticket/195
* Replaced deprecated DefaultHttpClient.Endi S. Dewata2016-11-041-11/+7
| | | | | | | The deprecated DefaultHttpClient in SubsystemClient, CRMFPopClient, and OCSPProcessor has been replaced with HttpClientBuilder. https://fedorahosted.org/pki/ticket/2531
* Fixed resource leak in InhibitAnyPolicyExtension.Endi S. Dewata2016-11-041-3/+5
| | | | | | | | | | The InhibitAnyPolicyExtension has been modified to always close the DerOutputStream instance. The InhibitAnyPolicyExtDefault has been modified to wrap the original exception. https://fedorahosted.org/pki/ticket/2530
* Fixed resource leak in ExtendedKeyUsageExtension.Endi S. Dewata2016-11-031-3/+5
| | | | | | | | | | The ExtendedKeyUsageExtension has been modified to always close the DerOutputStream instance. The ExtendedKeyUsageExt has been modified to wrap the original exception. https://fedorahosted.org/pki/ticket/2530
* Fixed resource leak in OCSPNoCheckExtension.Endi S. Dewata2016-11-031-2/+4
| | | | | | | | | | The OCSPNoCheckExtension has been modified to always close the DerOutputStream instance. The OCSPNoCheckExt has been modified to wrap the original exception. https://fedorahosted.org/pki/ticket/2530
* Fixed resource leak in GenericASN1Extension.Endi S. Dewata2016-11-031-3/+4
| | | | | | | The GenericASN1Extension has been modified to always close the DerOutputStream instance. https://fedorahosted.org/pki/ticket/2530
generated by cgit (git 2.34.1) at 2024-06-30 02:15:37 +0000