Bug 1337583 - Produce non-CRLF output when generating CSR with keytool
Produce non-CRLF output when generating CSR with keytool
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: java-1.8.0-openjdk (Show other bugs)
Unspecified Unspecified
urgent Severity high
: rc
: ---
Assigned To: Andrew John Hughes
Lukas Zachar
: Regression, ZStream
Depends On:
Blocks: 1203710 1297579 1343832
  Show dependency treegraph
Reported: 2016-05-19 10:20 EDT by Bill Yodlowsky
Modified: 2016-11-03 18:56 EDT (History)
5 users (show)

See Also:
Fixed In Version: java-1.8.0-openjdk-
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1343832 (view as bug list)
Last Closed: 2016-11-03 18:56:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bill Yodlowsky 2016-05-19 10:20:30 EDT
Description of problem:

keytool is producing output with Carriage Returns + Line Feeds (DOS/Windows-style linefeeds) as opposed to UNIX (LF) linefeeds.

It seems to have been added as a result of this bug:
- https://bugs.openjdk.java.net/browse/JDK-8074935

Upstream added the following patches:
- http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cae3b7b19462
- http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/cae3b7b19462

These cause keytool to produce CR/LF output.  This is one hunk of the second patch linked above:

@@ -1343,7 +1346,7 @@
         crl.sign(privateKey, sigAlgName);
         if (rfc) {
             out.println("-----BEGIN X509 CRL-----");
-            out.println(Base64.getMimeEncoder().encodeToString(crl.getEncodedInternal()));
+            out.println(Base64.getMimeEncoder(64, CRLF).encodeToString(crl.getEncodedInternal()));
             out.println("-----END X509 CRL-----");
         } else {

This breaks compatibility with other tools in use, that do not expect CR's in the file.

We know we can use sed or dos2unix to convert the linefeeds, but this is viewed as a regression and an unnecessary extra step.

Ideally the CR+LF behavior could be reverted; less ideally having a commandline argument to produce LF output would be desirable.


Version-Release number of selected component (if applicable):


How reproducible:

Steps to Reproduce:
1. keytool -genkeypair -keysize 2048 -keyalg RSA -alias thing -keystore certstore.jks
2. keytool -certreq -v -alias thing -keystore certstore.jks -file csr.txt
3. cat -vet csr.txt

Actual results:

[ These were generated from the above, not real data ]

$ cat -vet csr.txt 

(notice the ^M at the end)

Expected results:

$ cat -vet csr.txt

Additional info:

This behavior is not present in java-1.7.0-openjdk-headless-
Comment 4 Andrew John Hughes 2016-05-19 11:17:13 EDT
It's not due to 8074935 as that's not yet included in our RPMs; it first appears in u92 which will form the basis of the July security update.

I agree this is a regression if it worked with 7 and will look into it ASAP.
Comment 5 Andrew John Hughes 2016-05-19 19:02:09 EDT
Reproduced the failure:

csr.txt.7u101: RFC1421 Security Certificate Signing Request, ASCII text
csr.txt.8u91:  RFC1421 Security Certificate Signing Request, ASCII text, with CRLF, LF line terminators
Comment 6 Andrew John Hughes 2016-05-19 22:50:32 EDT
The regression comes from:


This switched the PKCS10 code from using the internal sun.misc.BASE64Encoder to the new java.util.Base64 encoder. As a consequence, it switched to using a form of Base64 encoding suitable for MIME encoding in e-mails with CR+LF line endings. The new encoder allows line endings to be specified, whereas the sun.misc.BASE64Encoder just used the println() method of the PrintWriter, which uses the system line endings.

It looks like 8074935 is enabling the CRLF line endings, but it's just explicitly stating what was the default before. The default MIME encoder uses CRLF line endings and a limit of 76 characters. To bring the limit down to 64 in that fix, they need to also explicitly specify the line endings, but they haven't actually changed from before.

I certainly see no reason we can't switch it back to the system line endings, or better still, provide that as a keytool option. What the default should be I'm not sure, as there seems to be no strong specification on this for PKCS#10. I doubt the change was intentional and, from 8074935, it looks like this area is still undergoing testing.

I'll work on a patch.
Comment 7 Andrew John Hughes 2016-05-26 21:50:57 EDT
I have a patch that adds a -systemlineendings option to keytool, allowing the old behaviour with the system line endings to be used (i.e. LF instead of CRLF on RHEL systems).


$ keytool -certreq -v -alias thing -keystore certstore.jks -file csr.txt.8u92.noopt
$ keytool -certreq -systemlineendings -v -alias thing -keystore certstore.jks -file csr.txt.8u92.opt

$ file csr.txt.*
csr.txt.7u101:      RFC1421 Security Certificate Signing Request, ASCII text
csr.txt.8u91:       RFC1421 Security Certificate Signing Request, ASCII text, with CRLF, LF line terminators
csr.txt.8u92.noopt: RFC1421 Security Certificate Signing Request, ASCII text, with CRLF, LF line terminators
csr.txt.8u92.opt:   RFC1421 Security Certificate Signing Request, ASCII text

As you can see, the one where the new option is used has the same line endings as the one produced by OpenJDK 7u101.

The option seems the best way to retain both compatibility with earlier versions of 8 and with 7, but there's always the possibility that upstream may just see it as a regression in 8 that can be fixed by default.
Comment 20 errata-xmlrpc 2016-11-03 18:56:43 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.