Project

General

Profile

Actions
Copy link

Feature #13010

closed

Option to retain the existing serial number when renewing a CA or certificate

Added by Evren Yurtesen about 2 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
Low
Assignee:
Jim Pingle
Category:
Certificates
Target version:
2.7.0
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
22.05
Release Notes:
Default

Description

I believe this issue is related to Bug #11514 - "Renewing a self-signed CA or certificate does not update the serial number". The serial update should be an optional feature. Because when the serial is updated, all the user certificates created by the CA seem to become invalid for OpenVPN use.

The "X509v3 Authority Key Identifier" section of the client certificate has the serial of the CA certificate in client certificate. Serial was the only difference I saw between CLI updated CA cert vs GUI updated CA cert.

Updating CA certificate manually. Eg using:

openssl x509 -in ca.crt -days 36500 -out ca.crt.new -signkey ca.key

keeps the same serial and the resulting CA certificate can be used for OpenVPN connections with existing client certificates.

When CA is renewed using the GUI, OpenVPN client logs entries such as:

Mar 31 18:13:18 pfSense openvpn[37303]: VERIFY ERROR: depth=0, error=unable to get local issuer certificate: CN=openvpnsense, serial=1
Mar 31 18:13:18 pfSense openvpn[37303]: OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

Actions
Copy link
 #1

Updated by Jim Pingle about 2 years ago

  • Category changed from OpenVPN to Certificates
  • Assignee set to Jim Pingle
  • Priority changed from Normal to Low

It could perhaps be made optional but I've seen more trouble from retaining the serial than from changing it, though.

It might be better to have an option to exclude the CA serial number from being used in the authorityKeyIdentifier. There may be other ramifications from that, but it seems like a better idea than reusing a serial number.

Both could be options -- the serial on renew, the AKID part when creating the CA and perhaps also when renewing.

Actions
Copy link
 #2

Updated by Evren Yurtesen about 2 years ago

Excluding the CA serial from being used in future, in authorityKeyIdentifier, does not solve the immediate problem with existing certificates becoming invalid. But it could perhaps be implemented now so in future using random serials could be easier.

Perhaps it could be limited to CA serial only. It seems to be having a domino effect if it is changed. More and more people with aging CA certificates will hit this problem. It took me a while to understand why the renewed CA certificate from pfSense GUI did not allow connections anymore.

There is also a lot of confusing information in forums. For example this post claims the CA certificate can be renewed in place and suggests new certificate should just be given to clients only: https://forum.netgate.com/post/967192 : but this is clearly not the case right now.

What would be the worst issue if same serial is used for CA?

Actions
Copy link
 #3

Updated by Jim Pingle about 2 years ago

Evren Yurtesen wrote in #note-2:

Excluding the CA serial from being used in future, in authorityKeyIdentifier, does not solve the immediate problem with existing certificates becoming invalid. But it could perhaps be implemented now so in future using random serials could be easier.

I agree, that's why I suggested we look into both. Though messing with AKID may not end up being feasible.

Perhaps it could be limited to CA serial only. It seems to be having a domino effect if it is changed. More and more people with aging CA certificates will hit this problem. It took me a while to understand why the renewed CA certificate from pfSense GUI did not allow connections anymore.

CA serial or intermediate serial would be the only ones that matter. Server and user certs should never reuse a serial number -- you'd have no way to revoke a bad one. Which is part of why it's also bad for a CA, though usually if a CA needs revoked the whole thing would need redone anyhow.

It's not pfSense that cares in that instance it's the clients and browser. Firefox and others refuse to allow a certificate to reuse the serial and since the GUI cert is self-signed it's effectively both a CA and a server cert. The same rules don't apply there as they would for a CA which signs multiple certs.

There is also a lot of confusing information in forums. For example this post claims the CA certificate can be renewed in place and suggests new certificate should just be given to clients only: https://forum.netgate.com/post/967192 : but this is clearly not the case right now.

That thread was before the other change was made, so at the time it was likely true since the CA serial wouldn't have changed on renew.

What would be the worst issue if same serial is used for CA?

It's more about what we don't know than what we do know. Some client software is pickier about it than others. Technically you're supposed to change serials when renewing but it's not clear in the specs if that applies to CAs as well as certs or just certs.

Adding an option to retain the CA serial when renewing should be OK so long as it isn't a self-signed server certificate type situation as with the GUI cert, and the GUI doesn't have a way to generate one of those at the moment anyhow. So the code just needs to make sure the function that generates the self-signed GUI cert gets a new serial, but for regular CA entries it should be optional.

Actions
Copy link
 #4

Updated by Jim Pingle about 2 years ago

  • Tracker changed from Bug to Feature
  • Subject changed from Renewing a self-signed CA force updates serial (serial update should be optional during renewal) to Option to retain the existing serial number when renewing a CA or certificate
  • Status changed from New to In Progress
  • Affected Architecture deleted (All)

Adding the GUI option to retain the serial on renew was simple, so I took that route. The other change seems to be a bit too intrusive and prone to error.

Actions
Copy link
 #5

Updated by Jim Pingle about 2 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #6

Updated by Jim Pingle about 2 years ago

  • Target version set to 2.7.0
  • Plus Target Version set to 22.05
Actions
Copy link
 #7

Updated by Christopher Cope about 2 years ago

Tested on

22.05-DEVELOPMENT (amd64)
built on Thu Apr 14 06:20:52 UTC 2022
FreeBSD 12.3-STABLE

and it works, but it doesn't prevent the user from reusing the serial and renewing the GUI cert. Maybe remove the option in that case or at least provide a warning?

Actions
Copy link
 #8

Updated by Jim Pingle about 2 years ago

  • Status changed from Feedback to Resolved

Christopher Cope wrote in #note-7:

Tested on
[...]

and it works, but it doesn't prevent the user from reusing the serial and renewing the GUI cert. Maybe remove the option in that case or at least provide a warning?

It already has a warning about that in the option description and sets the default appropriately based on type (checked for CA, unchecked for certs).

Actions
Copy link

Also available in: Atom PDF