Name: boT120536 Date: 02/19/2001


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

The CA provides a valid RFC 1421 Base64 encoded format certificate
in response to the Certificate Signing Request generated by the
keytool -gencsr.

For example:
-----BEGIN CERTIFICATE-----
MIICtjCCAh+gAwIBAgIDJ4S4MA0GCSqGSIb3DQEBBAUAMIGHMQswCQYDVQQGEwJa
QTEiMCAGA1UECBMZRk9SIFRFU1RJTkcgUFVSUE9TRVMgT05MWTEdMBsGA1UEChMU
VGhhd3RlIENlcnRpZmljYXRpb24xFzAVBgNVBAsTDlRFU1QgVEVTVCBURVNUMRww
GgYDVQQDExNUaGF3dGUgVGVzdCBDQSBSb290MB4XDTAxMDIxODE2MDQ0OVoXDTAy
MDIxODE2MDQ0OVowgZAxCzAJBgNVBAYTAk5MMRAwDgYDVQQIEwdVdHJlY2h0MREw
DwYDVQQHEwhNYWFyc3NlbjEjMCEGA1UEChMaSiBBTkQgQiBDb21wdXRpbmcgU2Vy
dmljZXMxITAfBgNVBAsTGFNlY3VyZSBob3N0IHRyYW5zYWN0aW9uczEUMBIGA1UE
AxMLd3d3Lmo0Mi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL7vCYXG
mFZMZwA0Cp6jCj8iMMT3Ct9dokqIX0xTOU2rrz8Wf4EVqSkJ5CISjbXmn4KF5SHR
yMUj0hfsSGiyqAuBXDBrVKKgdfnr3HgVlz0uebXcxmvf6E98lRYaXSz6Jb44gVbR
QexWgS2kmIGYMVTv4DG+wYyhWQVGQoSB4quRAgMBAAGjJTAjMBMGA1UdJQQMMAoG
CCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAICvR64Uu
rKNnJWR4A73BkiESREHcbFbiQzw6bJEHigpntymVeAICwWi9lnmXFzsyNhYHzK6t
T+eEC8BSAJL7NtooND8jogVORMSZMOXMpMraZYhJsHa2wDyGcgFVvCsWOsV2B2cT
bmIfgpHydI/XCHdSYMANhLNh3L+j//XVW6A=
-----END CERTIFICATE-----

However this cannot be imported as is into the keystore using the
keytool -import command unless you delete the characters after
the "-----END" . Without deleting those characters
you get an "Unsupported encoding" error.

What is more, after importing the certificate and using the
keytool to list it in rfc format we get the response:

-----BEGIN CERTIFICATE-----
MIICmTCCAgKgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBhzELMAkGA1UEBhMCWkExIjAgBgNVBAgT
GUZPUiBURVNUSU5HIFBVUlBPU0VTIE9OTFkxHTAbBgNVBAoTFFRoYXd0ZSBDZXJ0aWZpY2F0aW9u
MRcwFQYDVQQLEw5URVNUIFRFU1QgVEVTVDEcMBoGA1UEAxMTVGhhd3RlIFRlc3QgQ0EgUm9vdDAe
Fw05NjA4MDEwMDAwMDBaFw0yMDEyMzEyMTU5NTlaMIGHMQswCQYDVQQGEwJaQTEiMCAGA1UECBMZ
Rk9SIFRFU1RJTkcgUFVSUE9TRVMgT05MWTEdMBsGA1UEChMUVGhhd3RlIENlcnRpZmljYXRpb24x
FzAVBgNVBAsTDlRFU1QgVEVTVCBURVNUMRwwGgYDVQQDExNUaGF3dGUgVGVzdCBDQSBSb290MIGf
MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1fZBvjrOsfwzoZvrSlEH81TFhoRPebBZhLZDDE19m
YuJ+ougb86EXieZ487dSxXKruBFJPSYttHoCin5qkc5kBSz+/tZ4knXyRFBO3CmONEKCPfdu9D06
y4yXmjHApfgGJfpA/kS+QbbiilNz7q2HLArK3umk74zHKqUyThnkjwIDAQABoxMwETAPBgNVHRMB
Af8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAIKM4+wZA/TvLItldL/hGf7exH8/ywvMupg+yAVM
4h8uf+d8phgBi7coVx71/lCBOlFmx66NyKlZK5mObgvd2dlnsAP+nnStyhVHFIpKy3nsDO4JqrIg
EhCsdpikSpbtdo18jUubV6z1kQ71CrRQtbi/WtdqxQEEtgZCJO2lPoIW
-----END CERTIFICATE-----

This is not customer friendly.

It was the keytool Java v1.3 documentation that leds us
to "work around" the "Unsupported encoding" bug.

-import {-alias alias} {-file cert_file} [-keypass keypass] {-noprompt} {-
trustcacerts} {-storetype storetype} {-keystore keystore} [-storepass
storepass] [-provider provider_class_name] {-v} {-Jjavaoption}
Reads the certificate or certificate chain (where the latter is supplied in a
PKCS#7 formatted reply) from the file cert_file, and stores it in the keystore
entry identified by alias. If no file is given, the certificate or PKCS#7 reply
is read from stdin. keytool can import X.509 v1, v2, and v3 certificates, and
PKCS#7 formatted certificate chains consisting of certificates of that type.
The data to be imported must be provided either in binary encoding format, or
in printable encoding format (also known as Base64 encoding) as defined by the
Internet RFC 1421 standard. In the latter case, the encoding must be bounded at
the beginning by a string that starts with "-----BEGIN", and bounded at the end
by a string that starts with "-----END".

This bug forces us to explain to our customers how they must edit the
encoded certificate which they do not need to do for any other certificate
management tool we are aware of.
(Review ID: 117211)
======================================================================