Certificate generated on new computer is missing Key Encipherment

Help
1

Hello

I renewed my certificate from a new computer, and a few things changed

  1. the certificate no longer includes the Key Encipherment value under the property Key usage
  2. the algorithm has changed from RSA to ECC
  3. My c# code is no longer able to read the private key from the certificate.

What did I do: After I installed certbot on my new computer I copied the contents of C:\Certbot from the old computer to the new, I wanted to keep all the settings and account data. Certbot created a new live-folder called tendfor.net-0001 instead of using the old folder tendfor.net when i ran the renew command.

How do I get certbot to generate certificates like the one my old computer produces?

My domain is:tendfor.net

I ran this command:
certbot certonly --manual --preferred-challenges dns -d *.tendfor.net,tendfor.net

It produced this output:
Saving debug log to C:\Certbot\log\letsencrypt.log
Certificate not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: C:\Certbot\renewal\tendfor.net-0001.conf)

What would you like to do?

1: Keep the existing certificate for now
2: Renew & replace the certificate (may be subject to CA rate limits)

Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate for *.tendfor.net and tendfor.net

Successfully received certificate.
Certificate is saved at: C:\Certbot\live\tendfor.net-0001\fullchain.pem
Key is saved at: C:\Certbot\live\tendfor.net-0001\privkey.pem
This certificate expires on 2023-07-13.
These files will be updated when the certificate renews.

NEXT STEPS:

  • This certificate will not be renewed automatically. Autorenewal of --manual certificates requires the use of an authentication hook script (--manual-auth-hook) but one was not provided. To renew this certificate, repeat this same certbot command before the certificate's expiry date.

If you like Certbot, please consider supporting our work by:

My web server is: nginx/Self hosted .net 6 application

The operating system my web server runs on is : Windows Server 2022

My hosting provider, if applicable, is: N/A

I can login to a root shell on my machine: Yes

I'm using a control panel to manage my site: No

The version of my client is : certbot 2.5.0

2

unlike RSA, ECDSA keys cannot be used for encrypt data, therefore cannot have key encipherment in ECC certificate Key Usage field.

Why your code need to read Key Usage in certificate?

ref: RFC 8813

4 Likes
3

Then you didn't get a certificate from Let's Encrypt?Nevermind, ECDSA, see below.

Why would you renew & replace an existing certificate if you're not changing anything of the certificate, as your command is not changing any properties of the certificate?

With regard to the key type: please see the Certbot documentation for the option --key-type. The default key type has changed since 2.0.0 and unfortunately there was a bug in Certbot that certificates issued by rather old versions of Certbot did not have any renewal configuration settings for the key type and Certbot just started issuing ECDSAs, even for existing RSA certs. This was fixed in Certbot 2.5.0, which you seem to be running as you said, so I'm not sure why it would change for you too. Maybe you renewed the cert with an older 2.x.x version before upgrading Certbot? Wait, a new lineage was created, which defaulted to ECDSA of course.

Hmm, interesting! I didn't know that! Thanks :slight_smile:

3 Likes
4

ECDSA certificate cannot have Key Encipherment in Key Usage, because ECDSA algorithm isn't designed to encrypt data, only sign data.

1 Like
5

Yes, thanks, I didn't know that, striked out my first comment :slight_smile:

2 Likes
6

Certbot creates a new folder when the domain names in the cert have changed. You have used various combinations in the past. Sometimes you include the apex name along with the wildcard and at other times not. (your cert history here)

Your latest cert has both names so you could just standardize on that and delete the other one. Or, use the --cert-name option to update the original and then delete the -0001 version. You will see this more clearly from this command

certbot certificates
3 Likes
7

I was blindly fumbling around, hoping renewing with various versions of certbot would solve my problem.

8

The simplest way would be revert to explicitly requesting RSA certificates, new certbot versions requests ECDSA certificate by default.

However I would still recommend you to review why your program need to read Key Usage. Does your program really need the key contained in the certificate to encrypt data? If you are to use the key to encrypt data, then you must use RSA certificates. ECDSA certificates cannot be used for this purpose.

3 Likes
9

Yes, I think so. I use the certificate for TLS as well as encrypting passwords before storing them in a database.

10

Then you must request RSA certificates.

2 Likes
11

OK, thank you. I will look in to the --key-type mentioned earlier and how to implement in a renewal request.

Versions of certbot i fumbled around with:

  • certbot 1.9.0 (old computer)
  • certbot 2.2.0 (new computer, first 511 attempts)
  • certbot 2.5.0 (new computer, still no joy and time to ask for help :slight_smile:
1 Like
12

The CA/Browser forum has recently voted on a new ballot which transitions having both Digital Signature and Key Encipherment on the same certificate is NOT RECOMMENDED:

Subscribers MAY wish to ensure key separation to limit the risk from such legacy protocols, and thus a CA MAY issue a Subscriber certificate that only asserts the keyEncipherment bit. For most Subscribers, the digitalSignature bit is sufficient, while Subscribers that want to mix insecure and secure ciphersuites with the same algorithm may choose to assert both digitalSignature and keyEncipherment within the same certificate, although this is NOT RECOMMENDED.

Since that's NOT RECOMMENDED, Let's Encrypt may at some point begin the process of removing keyEncipherment (of course, with plenty of warning). It may be prudent to plan that you may want to reconsider the way you use certificates here. Do you really need a publicly-trusted certificate tied to the key you're using for database encryption?

8 Likes
13

I resolved my issue by adding the argument --key-type rsa when renewing the certificate, using certbot 2.5.0.

certbot certonly --manual --preferred-challenges dns -d *.tendfor.net,tendfor.net --key-type rsa

Thank you to all who helped!

1 Like
14

@mcpherrinm Thank you for the information, will raise awareness internally.

No, I'm using a single certificate because it is possible and keeps things simpler for me (it is also used as a client auth certificate).

Manually renewing this one and installing it across our entire environment is hassle enough. (office nginx, multiple clients, multiple servers, Azure VMs).

1 Like
15

We highly recommend automating certificate renewal.

4 Likes
16

The X.509 keyEncipherment key usage field used to be set in the past for TLS server certificates, because RFC 2459 [+ later incarnations] requires it for key transport.

In the past, TLS has extensively used key transport mechanisms ("static RSA key exchange"). For example, in the very early SSLv2 days, static RSA key exchanges where the only supported key exchange method. Support for Diffie-Hellman key agreements were formally added with SSLv3.

The times have changed though and static RSA key exchanges have been long deprecated. They cannot provide perfect forward security, provide single point of randomness-failures, and are the root cause of the ever returning Bleichenbacher attacks (CCA2, DROWN, ROBOT, CAT, and many more...). Nowadays we have mostly moved off static RSA key exchanges and moved onto Diffie-Hellman based key agreements. TLSv1.3, the latest TLS version, has completly removed support for the legacy static RSA key exchanges.

Without the static RSA key exchange, the key encipherment key usage field is not required. Hence, if we don't want to support it anymore, removing it is fine from a technical perspective. Any modern TLS cipher suite configuration won't have this enabled anway.

The X.509 certificates provided by Let's Encrypt are intended only for TLS connections (as indicated in the extended key usage fields). Using them for any other purpose is against their intented usage, and is not what the root programs or Baseline Requirements curate them for. Hence using a Let's Encrypt certificate for data encryption is already a poor choice from the start and may cause both security risks and compatibility issues.

The ECDSA algorithm is indeed a signature algorithm (DSA = Digital Signature Algorithm), not a data encryption algorithm. Hence, encrypting data with ECDSA was never supported and there never was an ECC-based key transport algorithm in TLS. Therefore, setting the key encipherment field on ECDSA certificates would be technically wrong, and is consequently also forbidden by the BR's.

12 Likes
17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.