Bug 56178

Summary: keytool error: Invalid escaped character in AVA: - some characters must be escaped
Product: JMeter Reporter: Sebb <sebb>
Component: HTTPAssignee: JMeter issues mailing list <issues>
Severity: normal CC: p.mouawad
Priority: P2    
Version: 2.11   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   

Description Sebb 2014-02-22 12:11:56 UTC
Certain characters have special meaning to the keytool application when used in the command-line -dname parameter. For example:

keytool -genkeypair -dname "OU=Foobar, INC" -keyalg RSA -keystore proxyserver.jks -storepass password
keytool error: java.io.IOException: Incorrect AVA format


keytool -genkeypair -dname "CN=DOMAIN\USER" -keyalg RSA -keystore proxyserver.jks -storepass password
keytool error: java.io.IOException: Invalid escaped character in AVA: 'U'

The keytool doc [1] only mentions comma as requiring escape.
However there are some others that are apparently not allowed, such as + (plus). It also looks like ; (semi-colon) is not allowed without escaping

Unfortunately keytool complains if escaping is used when it is not necessary, so it's important to only escape where necessary.

The problem arises in JMeter because it uses the value of the system property "user.name" when creating the certificate. This defaults to the user login name, which may be of the form DOMAIN\USER.

The simplest solution would be to drop the user name from the certificate, however the intention is to identify to whom the certificate belongs.

The name needs to be sanitised somehow.
Not yet clear how to do this without perhaps losing useful information.

[1] http://docs.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html#DName
end of section refers to comma escaping
Comment 1 Sebb 2014-02-22 12:31:33 UTC
The issue was first noticed because of a user.name with the form


User names can potentially include punctuation (O'Reilly) and may have non-ASCII characters. And some OSes may allow arbitrary login names, so might allow +;, in names.

The simplest approach would be to just allow for the backslash case, and assume that the other cases cannot occur. If they do, then there is the work-round of overriding user.name - if necessary just for creating the certificate.

Experimentation shows that DOMAIN\USER will appear in the certificate as DOMAIN\\USER (other escapes are removed).
It might look better to display the field as DOMAIN/USER so rather than doubling backslashes they could be converted to forward slashes.
Comment 2 Sebb 2014-02-24 00:58:11 UTC
Initial workround - replace \ by /

URL: http://svn.apache.org/r1571123
keytool error: Invalid escaped character in AVA: - some characters must be escaped
Bugzilla Id: 56178

Comment 3 Philippe Mouawad 2014-03-22 21:27:42 UTC
Is this one fixed ?
Comment 4 Sebb 2014-03-22 22:37:14 UTC
The specific case that caused the original problem is fixed, however the general case - escaping characters that are special to AVA entries - is not.

But given that there is a work-round, I guess we can close the issue for now.
Comment 5 Graham Russell 2014-10-13 21:25:36 UTC
Looking at lines 72-74 of KeyToolUtils.java:
    String userName = System.getProperty("user.name"); // $NON-NLS-1$
    userName.replace('\\','/'); // Backslash is special (Bugzilla 56178)
    addElement(sb, "OU=Username: ", userName); // $NON-NLS-1$
it looks like the fix didn't actually do anything. Should we remove this code or replace line 73 with:
    userName = userName.replace('\\','/');
Comment 6 Felix Schumacher 2014-10-14 08:27:36 UTC
ate: Tue Oct 14 08:17:53 2014
New Revision: 1631670

URL: http://svn.apache.org/r1631670
Bug 56178 - Return value of String#replace has to be used.
Bugzilla Id: 56178

Comment 7 Felix Schumacher 2014-10-14 08:28:24 UTC
Thanks for the report.