Can't import SSL certificates: "Could not parse the PEM-encoded import data"

[nick_chevsky]

I'm trying to import an RSA private key and X.509 server certificate into an ICX6450-C12-PD running FastIron 08.0.30u as follows:

(config)#ip ssl private-key-file tftp 1.2.3.4 key.pem
Downloading RSA private key file, please wait...
Done.
Download RSA certificate data file to create the certificate.
(config)#ip ssl certificate-data-file tftp 1.2.3.4 cert.pem
Downloading RSA certicate data file, please wait...
Done.

Creating certificate, please wait...

This consistently fails with error:

Cert import failed....Could not parse the PEM-encoded import data

Things I've tried:

• 2048-bit and 1024-bit RSA keys
• Encrypted and unencrypted keys
  
• SHA-256 and SHA-1 signatures
  
• v3 and v1 certificates
• Bare-minimum certificates without any extensions
• Subject Name fields matching Brocade defaults
• LF and CRLF line endings
• No line breaks at all

Is this feature even functional at all? Neither the Command Reference nor the Security Configuration Guide specify supported file formats, but my test cases have covered even the most legacy, compatible extremes without success.

[nick_chevsky]

I finally figured this out. The problem was that, for the RSA private key, FastIron doesn't support PKCS #8 ("-----BEGIN PRIVATE KEY-----"); it only supports PKCS #1 ("-----BEGIN RSA PRIVATE KEY-----").

Most modern certification authorities use the PKCS #8 standard for private keys, which supports any cryptographic algorithm and prefixes the key with an ASN.1 value that specifies the key's type (1.2.840.113549.1.1.1 for RSA). FastIron chokes on this—it only expects an RSA key in the ancient PKCS #1 format, which is RSA-specific and not future-proof.

There are several things wrong here:

1. FastIron prints the same misleading error message ("Cert import failed") even when the problem was—as in this case—with the private key; not the certificate.
   
   
2. The second part of the error message ("Could not parse the PEM-encoded import data") further misleads one to believe the issue is on the outer layer, when the problem is actually at the ASN.1 level.
   
   
3. FastIron devices are the only hardware on our network that doesn't support PKCS #8 private keys.
   
   
4. The facts that (a) only PKCS #1 is supported and (b) PKCS #8 is not supported are not documented anywhere. Please add this to the manuals, at the very least.

[DGray]

People suggested how to do it. Here is an example that I tested and is working on my Brocade ICX6610-48P. Although ip ssl cert-key-size says "SSL server certificate key size (range: 2048 or 4096)" I found this only worked with 2048 sized keys. It also says in the documentation that it can be up to 4096 bits but that's not necessarily true. I guess it depends on the device, maybe newer models can support larger keys. Using 4096 for the CA is okay though.

1. Create new Root CA 

   printf "\e[32mGenerate new "$name" Root CA\e[0m\n" \
   pass='{{ pass }}' \
   name='{{ name }}' \
   openssl req \
       -newkey rsa:4096 \
       -sha512 \
       -passin pass:"${pass}" \
       -x509 \
       -nodes \
       -keyout "$name"Root.pem \
       -new \
       -out "$name"Root.crt \
       -subj "/CN="$name" Root CA" \
       -days 3650

2. Generate key in PKCS#1 format. Use the -traditional, see openssl-genrsa for more details. 

   openssl genrsa -traditional -out keyfile 2048

3. Export public key (not strictly necessary) 

   openssl rsa -traditional -in keyfile -pubout -out keyfile.public

4. Create certificate sign request 

   name='{{ name }}' \
   C='{{ country }}' \
   ST='{{ state/province }}' \
   openssl req \
       -new \
       -sha512 \
       -key keyfile \
       -subj "/C="$C"/ST="$ST"/O="$name" Network, Inc./CN=sw1.home.arpa" \
       -out certsignreq.csr \
       -reqexts SAN \
       -extensions SAN \
       -config <(cat /etc/ssl/openssl.cnf ; printf "[SAN]\nsubjectAltName=DNS:%s" "sw1.home.arpa")

5. Sign certificate request 

   name='{{ name }}' \
   openssl x509 \
       -req \
       -in certsignreq.csr \
       -CA "$name"Root.crt \
       -CAkey "$name"Root.pem \
       -CAcreateserial \
       -out certfile \
       -days 3650 \
       -sha512 \
       -extensions v3_ext \
       -extensions SAN \
       -extfile <(cat /etc/ssl/openssl.cnf ; printf "[SAN]\nsubjectAltName=DNS:%s" "sw1.home.arpa")

6. Run the commands on the switch 

   conf t
   crypto-ssl certificate zeroize
   ip ssl cert-key-size 2048
   ip ssl certificate-data-file tftp 192.168.1.51 certfile
   ip ssl private-key-file tftp 192.168.1.51 keyfile
   web-management https

[jijo_panangat]

Hi Basteagow,

Thanks for the insights and i'm glad you figured it out.
We'll review these inputs internally and see how we can overcome this,ICX6450 is a legacy and an EOS product hence the new changes are very unlikely.


Thanks
Jijo 

[timothy_harryma]

Same issue on ICX7150 running 08.0.90d (UFI)  Like Basteagow, I needed to use the PKCS #1 format for this to work.  I also found that it is not documented.

I would like to sincerely thank Basteagow for spending the time to figure this out, and express my hope that the documents are updated to prevent others from having to go through the same process of trial and error.