-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
disable unique_subject or document it #40
Comments
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- notifications@github.com wrote:
|
Sounds reasonable. Maybe add a command "renew-cert" to the tool, which overrides this setting just for this command? |
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- notifications@github.com wrote:
|
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. |
Yes, revoking it, or waiting for it to expire will solve this. This might work for some people. 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. |
I got an even worse problem: I enabled unique_subject again, keeping the index.txt:
and could not sign a new req without disabling unique_subject again: Even with this fixed, the
|
This isn't something I want to support right now. Eric F Crist On Sep 19, 2014, at 10:20:36, ChristianTacke notifications@github.com wrote:
|
@ecrist What do you not want to support?
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. |
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(?)). |
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. |
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 notifications@github.com wrote:
|
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. |
unique_subject should be NO, according to official openssl website documentation. https://www.openssl.org/docs/manmaster/apps/ca.html "unique_subject |
For the use case of a VPN, as EasyRSA was originally intended, the current setting is best.
|
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. |
To me the Wouldn't it be useful to allow the easy-rsa user to override this behavior temporarily? Thus setting 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. |
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. |
By the way, you're using old EasyRSA, the new one has only the "easyrsa" command. |
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:
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. |
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: |
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.
|
For re-issuing expired certificates, unique_subject in index.txt.attr needs to be "no" |
Linking: #394 |
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.
The text was updated successfully, but these errors were encountered: