Bug 1337583

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.

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

The regression comes from:

https://bugs.openjdk.java.net/browse/JDK-8006182

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.

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).

e.g.

$ 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.

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.

https://rhn.redhat.com/errata/RHEA-2016-2139.html

keytool maintainer from Oracle's Java SE security team here. Sorry I've just noticed this bug.

(In reply to Bill Yodlowsky from comment #0)
> This breaks compatibility with other tools in use, that do not expect CR's
> in the file.

Can you be specific what other tools do not parse the new format?

> $ cat -vet csr.txt 
> -----BEGIN NEW CERTIFICATE REQUEST-----$
> MIIC4TCCAckCAQAwbDEQMA4GA1UEBhMHVW5rbm93bjEQMA4GA1UECBMHVW5rbm93bjEQMA4GA1UE^
> M$
> BxMHVW5rbm93bjEQMA4GA1UEChMHVW5rbm93bjEQMA4GA1UECxMHVW5rbm93bjEQMA4GA1UEAxMH^
> M$
> [snip]
> 7spEik5L0m1JgP87BIZM2Nk/2/1+E5dfd3lkD6RtJkxecTbBMZ1UKsp0KGBvwagT+Gx82GPFmXjH$
> -----END NEW CERTIFICATE REQUEST-----$
> 
> (notice the ^M at the end)

You can see that the header and footer end with \n but the BASE64 encoded lines end with \r\n. This is definitely an inconsistency and we should fix it. Could this be the reason your other tools cannot deal with them?

As for a new option "-systemlineendings", I cannot be sure if it's the best solution at the moment. There are other cases in keytool that prints out certificates and CRLs in PEM. It looks like if we introduce this option it should apply to all commands.

Also, how can someone using a Windows system create a PKCS #10 file in Linux format? :-)

We fixed this some time ago, but haven't been able to submit it upstream just yet. The new aggressive release cycle of OpenJDK isn't helping, when the previous version is required to build the current one.

https://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/794541fbbdc3

Looking through the keytool code again, we could indeed move this to a top-level option and apply it to the other CRLF cases. At the time, we just needed a quick fix for the customer's issue. I'll look into this when I post it upstream.

On the last comment, we could instead provide a -lineendings option with CR, CRLF, LF and system as options. This is really a discussion for the mailing list though.