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.
Related
I am working on an application hosted on Heroku that communicates with an apple system that requires SSL certificates to be in place. Apple requires that an ECC certificate be used where Heroku does not support ECC certificates - only RSA.
I am curious to know if I can generate my signing request with an ECC signature and use this to generate the certificate from apple but then convert this ECC key to an RSA key so that Heroku can still interpret this.
Do I have a drastic misunderstanding of how these two certificates are implemented that means this approach is not possible or do I just need to do the right openSSL commands to the cert to generate the key formats I need?
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.
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.
I need information related to ECDSA certificates. As far as I know ECDSA certificate should contain the ECDSA signature but I see that facebook and google server certificates have the ECDSA certificates with RSA signature.
Is it possible to have the ECDSA certificates with RSA signatures?
The signature for a certificate is created by the issuer using the key of the issuer. Thus if the certificate A has an ECC key inside (i.e. ECDSA certificate) but the issuer B has an RSA key then the signature for A will be an RSA signature, because this is what the issuer has for signing.
For example in the case of facebook.com the certificate itself has an ECC key, but the issuers certificate DigiCert SHA2 High Assurance Server CA has an RSA key. Because the signature for the facebook certificate is done by the issuer with the issuers key it must use RSA too.
Steffen's answer is correct for X.509 standard and many browsers
which are based on standard SSL libraries support the case. However, in this rough real world, I found some devices rejecting ECDSA certificate which has RSA signatures, with TLS 1.2 negotiation.
I think the reason is that the authors of the devices followed the RFC-4492, (** is mine)
2.2. ECDHE_ECDSA
In ECDHE_ECDSA, the server's certificate **MUST** contain an ECDSA-
capable public key and **be signed with ECDSA.**
The server sends its ephemeral ECDH public key and a specification of
the corresponding curve in the ServerKeyExchange message. These
parameters MUST be signed with ECDSA using the private key
corresponding to the public key in the server's Certificate.
though RFC-5246, TLS1.2, loosened this restriction. (** is mine):
7.4.4. Certificate Request
...
If the client provided a "signature_algorithms" extension, then all
certificates provided by the server MUST be signed by a
hash/signature algorithm pair that appears in that extension. **Note
that this implies that a certificate containing a key for one
signature algorithm MAY be signed using a different signature
algorithm (for instance, an RSA key signed with a DSA key). This is
a departure from TLS 1.1, which required that the algorithms be the
same.** Note that this also implies that the DH_DSS, DH_RSA,
ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
algorithm used to sign the certificate. Fixed DH certificates MAY be
signed with any hash/signature algorithm pair appearing in the
extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are
historical.
So be warned that such a device exists.