The hardcoded implication of -new with -x509 in openssl req command breaks some use-cases #3396
Comments
|
Ping, can you please at least tell whether you consider this breakage as a bug or not and the current behavior will be kept? |
|
Seems like a bug. A bit tricky to figure out the right thing to do tho. |
|
Ping @levitte. Thoughts? |
|
I don't think this was an intentional breakage... In other words, I'm inclined to see this as a bug that happened with the option processing changes about a year ago... So I'd say this is a bug and should be fixed. |
t8m
added a commit
to t8m/openssl
that referenced
this issue
May 11, 2017
Allow conversion of existing requests to certificates again. Fixes the issue openssl#3396
t8m
added a commit
to t8m/openssl
that referenced
this issue
May 17, 2017
Allow conversion of existing requests to certificates again. Fixes the issue openssl#3396
2 tasks
pracj3am
pushed a commit
to cdn77/openssl
that referenced
this issue
Aug 22, 2017
Allow conversion of existing requests to certificates again. Fixes the issue openssl#3396 Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from openssl#3437) (cherry picked from commit 888adbe)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This commit
599e590
and equivalent on 1.0.2 branch broke legitimate use-case.
Namely you can generate a request with openssl req invocation and then later you want to convert it to self-signed x509 certificate via the openssl req -x509 command. The -new should not be implicitly set at least for the case the command line specifies -in <cert.req> option. There it is clear that user does not want to generate a new request but wants to read existing request file.
The text was updated successfully, but these errors were encountered: