Elasticsearch version: Version: 6.2.4, Build: ccec39f/2018-04-12T20:37:28.497551Z, JVM: 1.8.0_172
Description of the problem: Using a long password (ex. 64 characters: 2zVBXLjRzAXn9wcXuj6vr@YVVAMwiEBJvhFp,cPpoK&ZVLXhWsw2#%PzyjJkZiWx), certutil allows creation of the keypair but the password does not work.
Steps to reproduce:
bin/x-pack/certutil ca --ca-dn "CN=Example LLC" --days 7300 --keysize 40962zVBXLjRzAXn9wcXuj6vr@YVVAMwiEBJvhFp,cPpoK&ZVLXhWsw2#%PzyjJkZiWx at the prompt for the passwordopenssl pkcs12 -in Example.p12 -infoPinging @elastic/es-security
I think it's reasonable to at least warn users if they're creating keystores that cannot be handled by common tooling.
Hi,
I would like to work on this. Can I?
@khanf9 Go ahead.
You'll need to start with org.elasticsearch.xpack.core.ssl.CertificateTool
Please have a look and then let us know how you plan to tackle this - there's a few different ways to resolve this issue, so it's probably worth running your proposal by us before you do too much work.
@jkakavas @tvernum
Can you guys help me understand why aren't we updating OpenSSL version >= 1.1.0? Is it being worked on? or is there some useful functionalities in current version important for certutil.
My plan was to generate a warning dynamically by identifying the version of Openssl being used.
@khanf9 certutil doesn't depend on, or use openssl. The issue is that certutil will happily generate files that older (but widely deployed) versions of openssl cannot read.
We'd like to have something in place that warns or prevents users from doing that accidentally.
@tvernum I have some thoughts on this...
password.length <= MAX_OLD_OPEN_SSL_PASSWORD_LENGTH returning bool.Terminal.promptYesNo question if the entered password exceeds 50 characters. Something likeYour password exceeds a length of 50 characters. Versions of OpenSSL older than 1.1.0 will not be able to use this certificate. Do you want to continue? [Y / n]However I'm looking for a good place for the check and the prompt...
What do you think?
Hi,
I would like to work on this issue.
@Seeraeuber Sorry, I issued your earlier plan. That seems like a good plan of attack.
From memory, putting on the password check will be the hardest part, because of the use and structure of withPassword.
I think the simplest approach will be to add a boolean argument to withPassword that controls whether the password should be checked for length.
Do you still want to work on this, or can @MiguelFerreira1998 take it on?
@tvernum Me and @MiguelFerreira1998 are currently working on this issue and we already made some changes to the code elastic/elasticsearch/blob/master/x-pack/plugin/security/cli/src/main/java/org/elasticsearch/xpack/security/cli/CertificateTool.java and we need some help to test the issue. I think the 'steps to reproduce' told by @jpcarey are deprecated. What should be our approach?
bin/elasticsearch-certutil ca --ca-dn "CN=Example LLC" --days 7300 --keysize 4096 -out Example.p12 --pass "2zVBXLjRzAXn9wcXuj6vr@YVVAMwiEBJvhFp,cPpoK&ZVLXhWsw2#%PzyjJkZiWx" openssl pkcs12 -in Example.p12 -info@bedgarone when you say:
we need some help to test the issue
do you mean to reproduce it (for which @jpcarey has provided the steps, presuming you have an openssl version < 1.1.0), or to write a test case for it?
For the test case you'd simply want to write a test that tries to generate a certificate with a password between 50 and 2048 characters long, and then ensure that the prompt proposed by @Seeraeuber was put to the terminal.
@tvernum We need to know how we can get the current version of the user's openssl, so that the verification runs only for older versions.
Thanks for your time.
Most helpful comment
@tvernum Me and @MiguelFerreira1998 are currently working on this issue and we already made some changes to the code
elastic/elasticsearch/blob/master/x-pack/plugin/security/cli/src/main/java/org/elasticsearch/xpack/security/cli/CertificateTool.javaand we need some help to test the issue. I think the 'steps to reproduce' told by @jpcarey are deprecated. What should be our approach?