disable unique_subject or document it

[openvpn]

disable unique_subject or document it

[allo-]

Sounds reasonable. Maybe add a command "renew-cert" to the tool, which overrides this setting just for this command?

[ecrist]

If I remember correctly, openssl allows you to issue a new certificate once a certificate with the same CN has either expired or been revoked.

---

Eric F Crist

On Sep 15, 2014, at 14:32:27, allo- [email protected] wrote:

Sounds reasonable. Maybe add a command "renew-cert" to the tool, which overrides this setting just for this command?

—
Reply to this email directly or view it on GitHub.

[allo-]

I guess a commandline parameter could override the config setting. So a renew command could do this and providing a whole "renew" command could do other sanity checks (i.e. is there really a previous cert?) as well.

[rct]

I ran into this right away during the learning phase of upgrading from 2.0 to 3.0.1. It is easy to make a mistake, and non-obvious how to correct it. Note:

• Revoke doesn't clean up the old certificate files. So it can take up to 4 steps - 1. Run revoke, 2. try to recreate, and get told you need to delete .req, .key, .cert in up to 3 separate invocations.
• If you try to optimize by deleting the old cert files first, you can't run revoke.

As i understand this, I'm going to trip over this when I need to renew VPN certs. There is a window when I'd like to be able to issue renewed certs before expiration. I think this is a reasonable use case.

[ecrist]

Unique subject should be enforced to ensure multiple certificates with the same common name are not issued.

---

Eric F Crist

On Sep 15, 2014, at 14:28:34, allo- [email protected] wrote:

For re-issuing expired certificates, unique_subject in index.txt.attr needs to be "no". This is neither default, nor documented, while the tool issues certificates with a limited lifetime by default.

—
Reply to this email directly or view it on GitHub.

[allo-]

It did not work for me, and i found http://pyro.eu.org/how-to/micro/openssl-txt_db-error-number-2.txt as solution. I did not test revocing.

[ChristianTacke]

Yes, revoking it, or waiting for it to expire will solve this. This might work for some people.
But in many cases, you want to smoothly migrate a month before the old certificate expires. You want to give the new one to the user, while the old still works (until they update). That's a quite common way of operation for distributed deployments. Users might even fetch their new certificate while being connected using their old cert!

My current way of operating things: Have the date (year-month) in the filename, but a CN distinguishing the actual user.

I really don't understand, what this feature is going to stop. Giving the same CN to different users? If you want to do that, you will likely just give the exact same key/cert to different users!

Anyway, if you want to keep this default, please add an option to build-ca, so people have a choice.

[allo-]

I got an even worse problem: I enabled unique_subject again, keeping the index.txt:

V   240911170906Z       01  unknown /CN=server
V   140915171946Z       02  unknown /CN=allo
V   141214192323Z       03  unknown /CN=allo

and could not sign a new req without disabling unique_subject again:
error creating name index:(2,1,2)

Even with this fixed, the sign-req command could use a third option to change the common name:

$ ./easyrsa sign-req client allo allo-2nd-cert

[ecrist]

This isn't something I want to support right now.

---

Eric F Crist

On Sep 19, 2014, at 10:20:36, ChristianTacke [email protected] wrote:

Yes, revoking it, or waiting for it to expire will solve this. This might work for some people.
But in many cases, you want to smoothly migrate a month before the old certificate expires. You want to give the new one to the user, while the old still works (until they update). That's a quite common way of operation for distributed deployments. Users might even fetch their new certificate while being connected using their old cert!

My current way of operating things: Have the date (year-month) in the filename, but a CN distinguishing the actual user.

I really don't understand, what this feature is going to stop. Giving the same CN to different users? If you want to do that, you will likely just give the exact same key/cert to different users!

Anyway, if you want to keep this default, please add an option to build-ca, so people have a choice.

—
Reply to this email directly or view it on GitHub.

[ChristianTacke]

@ecrist What do you not want to support?

1. disabling unique_subject
2. enhancing sign-req?

IMHO enhancing sign-req is something for another issue/enhancement-request.

But a simple start for unique_subject shouldn't be too hard? Add unique_subject = ENV:EASYRSA_UNIQUE_SUBJECT in openssl.cnf and preset that variable with yes and let people change it to no. They need to do that before creating the CA, but that's already much better than now.

[allo-]

Both are related, as the extended sign-req would allow to sign a req again and again with changed common name (which could be non-trivial, as the CSR needs to be changed(?)).

[ChristianTacke]

Yes, it would help mitigate this.

Well, for the time being, I have patched my local openssl.cnf and the one we're going to ship to customers. Because the CN is being used in openvpn for matching things.

[ecrist]

Remember, what you put in your openssl.cnf file is completely up to you, and NOT something that needs to be, or should be, supported by easy-rsa. Just understand that they're local changes and your internal defaults don't need to be part of our code base.

---

Eric F Crist

On Sep 19, 2014, at 14:02:26, ChristianTacke [email protected] wrote:

Yes, it would help mitigate this.

Well, for the time being, I have patched my local openssl.cnf and the one we're going to ship to customers. Because the CN is being used in openvpn for matching things.

—
Reply to this email directly or view it on GitHub.

[ChristianTacke]

I do understand that very well.

I just think, that supporting that in a proper way in the main code base would benefit many people.

[mailinglists35]

unique_subject should be NO, according to official openssl website documentation.
accordingly, easy-rsa should adopt the upstream recommendation!

https://www.openssl.org/docs/manmaster/apps/ca.html

"unique_subject
if the value yes is given, the valid certificate entries in the database must have unique subjects. if the value no is given, several valid certificate entries may have the exact same subject. The default value is yes, to be compatible with older (pre 0.9.8) versions of OpenSSL. However, to make CA certificate roll-over easier, it's recommended to use the value no, especially if combined with the -selfsign command line option."

[ecrist]

For the use case of a VPN, as EasyRSA was originally intended, the current setting is best.

On Oct 21, 2015, at 10:56 AM, mailinglists35 [email protected] wrote:

unique_subject should be NO, according to official openssl website documentation.
accordingly, easy-rsa should adopt the upstream recommendation!

https://www.openssl.org/docs/manmaster/apps/ca.html

"unique_subject
if the value yes is given, the valid certificate entries in the database must have unique subjects. if the value no is given, several valid certificate entries may have the exact same subject. The default value is yes, to be compatible with older (pre 0.9.8) versions of OpenSSL. However, to make CA certificate roll-over easier, it's recommended to use the value no, especially if combined with the -selfsign command line option."

—
Reply to this email directly or view it on GitHub.

[allo-]

Did you put some documentation about this feature somewhere, when you now do not want to change the default? Because it's kind of a gotcha.

[tvannahl]

To me the unique_subject = yes is great for preventing me signing already existing VPN users, but since those users need their new certificates ahead of the expiration date I had to change that value.

Wouldn't it be useful to allow the easy-rsa user to override this behavior temporarily? Thus setting unique_subject = no but by checking if an certificate with that name already exists. If such an certificate already exists lets show that by not updating the database, but give the user the ability to use either ./renew-cert or ./build-req --renew. I would not favor an input during creation, because something likes this is to easy to be ignored.

These are just my 50cent regarding that because I've just searched the x-th time regarding that topic. And this is the first time I've encountered at least as solution on which I don't have to edit the 'database' manually.

[allo-]

By the way, you're using old EasyRSA, the new one has only the "easyrsa" command.

[ahmadkarim]

so is there any way to renew client certificate before they expire? . I have embedded devices that are located in different cites and connected to my open vpn server. Now the time has come where the certificates are about to expire. How can i renew the certificates on these devices using the same name.

My proposed solution:
A script on the device checking the validity of the certificate and before it expires it sends a request through the tunnel asking for a new certificate, but the problem is i can not use the same name, and in worst case if the certificate is expired how can i identify if the request is coming from my device and not some one else

[ecrist]

Thee is an OpenSSL option to allow duplicate CN. I don’t recall what it is offhand, but should be a quick google search for you. Set that value for EasyRSA and it should work. You will still need to distribute the certificates and new keys to the devices though. Eric Crist

…

On Aug 8, 2018, at 9:00 AM, Ahmad Karim ***@***.***> wrote: so is there any way to renew client certificate before they expire? . I have embedded devices that are located in different cites and connected to my open vpn server. Now the time has come where the certificates are about to expire. How can i renew the certificates on these devices using the same name. My proposed solution: A script on the device checking the validity of the certificate and before it expires it sends a request through the tunnel asking for a new certificate, but the problem is i can not use the same name, and in worst case if the certificate is expired how can i identify if the request is coming from my device and not some one else — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

[allo-]

Thee is an OpenSSL option to allow duplicate CN.

For re-issuing expired certificates, unique_subject in index.txt.attr needs to be "no"

[TinCanTech]

Linking: #394