I have a certificate in a .PEM file and a key.
The signing algorithm of the certificate file is SHA256WithRSAEncryption but when I create a p12/pfx file using the certificate file and the key the Signature Algorithm of p12/pfx file changes to
"PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048"
Is there a way I can get a SHA-2 certificate after the process?
The certificate lists the algorithm used to sign the certificate, while the PKCS#12 store lists the method that was used to encrypt the key / certificate store.
PBE stands for Password Based Encryption, and the SHA-1 is only applicable to the way the password is transformed into a key; it has nothing to do with the certificate itself. The same certificate is still in the store if everything went well.
Notes:
Also in there is 40 bit RC2 and a low iteration count; this provides next to no security. So if you're using this to protect the private key you'll have to start over again;
The RSA key pair for the certificate can be used to perform signature generation / verification with any hash algorithm (if non-repudiation or authentication is compatible with the key usage of the certificate), not just the one used to sign the certificate itself.
Related
I have a root certificate with a Signature algorithm md5RSA which is currently used by our clients.
I wish to create another root certificate with Signature algorithm ECDSA SHA-256 that will be above the older certificate in order to be backward compatible (so clients could authenticate with both the older MD5 certificate and the newer SHA-256 certificate using WCF).
How can i achieve this?
Thanks.
I need to create a certificate for e-mail signing. Due to local regulation I have specific requirements for the certificate and the keys.
I am not a certificate expert at all, so I am totally unsure which kind of certificate I need to buy, whether I need a CSR, how to create the keys.
These are the requirements:
Signature:
Hash algorithm: SHA-256 oder SHA-512 (IETF RFC 5754)
Signature algorithm: RSASSA-PSS (IETF RFC 4056)
Encryption:
Key encryption: RSAES-OAEP (IETF RFC 3447)
Content encryption: AES-128 CBC oder AES-192 CBC (IETF RFC 3565).
RSA key length: at least 2048 Bit
Key-Usage: Digital signature, key encryption
Can someone explain which steps I need to perform to get a .cer-file which complys with the above regulation?
You need to:
Acquire the OpenSSL command-line tool.
Acquaint yourself with its overall command-line structure.
Generate a key-pair with the required characteristics.
Generate a CSR with the required characteristics.
Submit the CSR (and not the key-pair) to a Certificate Signing Authority (CA) stating that it is for signing prtposes, not for SSL.
Import the signed certificate and its key chain back into the same files the CSR came from, again via the OpenSSL tool.
I have a self signed CA which has 1024 bit key length. Is it possible to sign a server certificate with longer key length (2048 bit) using this CA? I want to sign a server certificate and configure that for Active Directory service.
I'm able to do this using bouncy castle. My concern is about
1) Is this a good idea?
2) How would the certificate trust be established? Would that be okay.
Yes, you can use your 1024-bit RSA private key to sign a certificate for a server that is using a 2048-bit key. The length, and even the type, of the key in the certificate you're signing (the server's certificate) has no relation to the key you're using to do the signing. For example, you could have your 1024-bit RSA private key sign a certificate for a server using a 256-bit EC key if you wanted.
(Technically, you aren't signing the certificate itself, but a hash of the certificate. See this question and answer for details. But conceptually, you can think of it as "signing the certificate".)
Trust is established the same as with any other certificate chain:
Your client contains your CA's 1024-bit public key in its trust store.
Your client connects to a server, which sends its certificate, signed by your CA.
Your client sees that the certificate is signed by a CA in your trust store, so it verifies the CA's signature on the server's certificate using the CA's public key in the client's trust store.
The signature matches, so the client trusts the server's certificate.
Using EJBCA (6.2.0), after adding an ecdsa entity certificate on the Ejbca's "Admin" server, I tried to use the Ejbca public web to enroll this entity certificate, however, it only provides the choice to select RSA key bit length but not the named curves that I need ( note: I have all the certificate CA, profile configured as ECDSA). After spending few days to google on this topic, I come to the impression EJBCA only capable of using ECDSA to sign certificate but not to generate ECDSA keys!
I wonder if there is a way to workaround this issue ? Any help is greatly appreciated !
Thanks,
Harold T
This depends on which key pair you are generating. When generating a CA in EJBCA up to three keys and certificates are generated:
A CA signing keypair and certificate
An encryption keypair, used for encrypting keyrecovery information
An OCSP signer keypair and certificate
When using ECDSA keys, the CA signing keypair and the OCSP signer keypair will be the ECDSA keytype you select when creating the CA. The CA signing and OCSP signing certificate will be signed using your selected signature algorithm.
The encryption keypair will always be RSA, using 1024 or 2048 bit key length. It uses the key length set in the admin-GUI or 2048 bit by default using the cli. A dummy encryption certificate will be created using SHA1WithRSA.
using batch tool you can edit conf/batchtool.properties to achieve what you are asking for.
Future versions will support it in the gui as well.
We are in the process of setting up AS2 over https. https uses asymmetric key encryption and the certs are signed by a common CA. AS2 uses symmetric key encryption.
For AS2, it is my understanding that:
setting up a self-signed key (and exporting the cert or public key) is sufficient.
All I need to do next is pass on the cert to the trading partner
there isn't much advantage in getting the AS2 cert signed by a CA
if I do get the cert signed by a CA (say VeriSign), the advantage will be that I do not need to send the cert to the trading partner (effectively step 2 is not required)
Let me know if the above is correct.