I'm trying to generate a certificate for my web server with Let's Encrypt. I want to manually generate key and csr with openssl, and then use letsencrypt / certbot to get the certificate. I specifically want the certificate to use sha256withecdsa. In particular I would like to use the curve secp521r1 (a.k.a. P-521).
The key generation and csr generation work fine, however, when I input the command
certbot certonly --apache -d [censored] --csr mycsr.csr --agree-tos
I get the following error:
The request message was malformed :: Invalid key in certificate request :: ECDSA curve P-521 not allowed
Is ECDSA still unsupported, or am I doing anything wrong?
While P-521 is valid for use in X.509 certificates, most browsers dropped support for it as it is not a part of Suite B and isn't very popular. As a result, Certbot doesn't allow certificates to be generated using P-521 since the browsers would reject it anyway. You can still generate certificates using the P-256 and P-384 curves. See the Mozilla and Google bugreports for details.
Besides my comments on #AfroThundr reply, in fact the definitive source of information on this is https://letsencrypt.org/docs/integration-guide/ and it says:
Supported Key Algorithms
Let’s Encrypt accepts RSA keys from 2048 to 4096 bits in length, and P-256 and P-384 ECDSA keys. That’s true for both account keys and certificate keys. You can’t reuse an account key as a certificate key.
Our recommendation is to serve a dual-cert config, offering an RSA certificate by default, and a (much smaller) ECDSA certificate to those clients that indicate support.
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'm using cUrl to request data from a corporate website site using a .cer certificate that they sent me.
This is the command:
cUrl --header "Content-Type: text/xml;charset=UTF-8" \
--data #bustaRequestISEE2015ConsultazioneAttestazione.xml \
-o bustaResponseISEE2015ConsultazioneAttestazione.xml \
--cert ./caaffabisrl.cer \
https://istitutonazionaleprevidenzasociale.spcoop.gov.it/PD
When I run it, I get this error message:
curl: (58) could not load PEM client certificate, OpenSSL error error:0906D06C:PEM routines:PEM_read_bio:no start line, (no key found, wrong pass phrase, or wro
ng file format?)
Is there anybody who can help me?
Tks, Cristiano.
It is not possible to connect to a TLS server with curl using only a client certificate, without the client private key. Either they forgot to send you the private key file, or, what they sent you was not the client certificate but the server certificate for verification.
The first thing I would try is using --cacert instead of --cert. That is, tell curl that this is the server's certificate that curl can use to verify that the server is who you think it is.
You can also try removing --cert and not using --cacert, and you will probably get an error that the server is not trusted. Then add the --insecure argument and see if that works. I would not keep that argument, as then you have no proof of who you are talking to.
My guess is that it is the server cert, and that using --cacert instead of --cert will solve the problem.
My guess is that your certificate file is a DER encoded binary certificate instead of base-64 encoded certificate. To covert the from binary to base-64, you can use OpenSSL.
openssl x509 -inform der -in certificate.cer -out certificate.pem
I always forget all the arguments and have the following site bookmarked, as it gives examples of how to convert pretty much any certificate format. https://www.sslshopper.com/ssl-converter.html
First, you need to specify whether you're expected to perform two-way TLS/SSL or MTLS (mutual TLS). This would typically be the reason for sending a certificate. If they sent the server certificate, but you can connect to the server with a browser, you can down load the certificate. If their server is configured to send the server certificate and CA chain, then you can get the entire chain in a single request using "openssl s_client -connect [hostname:port] -showcerts". Save the certs in the console to a file, copying the cert blob(s) to individual cert files (cert1.crt, cert2.crt). However, if they are expecting MTLS and attempting to send a client certificate to you, either you've already generated a private key and CSR (certificate signing request) and send them the CSR. They would have then signed a certificate with their CA certificate using the CSR. The cert they returned would then need to be paired with the private key used to generate the CSR. They should not be generating the public/private key pair and sending them over mail. The private key should be stored security on the one system used to establish the connection. If it's one-way (server ssl only), then your client system (assuming it's not the browser), needs a truststore file, with the CA certificate chain installed and set to trusted. If the platform is Java, read Java's keytool documentation. Note, a keystore is for your systems public/private keypair. A truststore is for the CA certificates that you trust to sign public certificates that your system should trust as being authentic. You need to read any of the PKI x509 overviews by DigiCert, SSLABS, Sectigo, etc.
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.
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.