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

  • 1
  • Question
  • Updated 3 days ago
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.
Photo of basteagow

basteagow

  • 9 Posts
  • 3 Reply Likes
  • frustrated

Posted 1 week ago

  • 1
Photo of Jijo Panangat

Jijo Panangat, Employee

  • 102 Posts
  • 35 Reply Likes
Hello basteagow

Have you already tried with the filename without extensions, like the one below.

(config)#ip ssl certificate-data-file tftp 192.168.9.210 certfile
(config)#ip ssl private-key-file tftp 192.168.9.210 keyfile

We would need a debugging session to have a better understanding of the problem, Could you please open a tac case.


Thanks
Jijo
Photo of basteagow

basteagow

  • 9 Posts
  • 3 Reply Likes
I have, yes, but the filenames aren't the problem—the switch is successfully downloading both files, and the TFTP server's logs confirm this.

I tried enabling debug ip ssl, but no log entries are generated during the import process. Is there somewhere else I can look for debug info?

Can you post a sample key/certificate pair that successfully imports for you, and specify the switch model and FastIron version on which it succeeds? If your files fail to import for me, we can then narrow this down further.
(Edited)
Photo of Jijo Panangat

Jijo Panangat, Employee

  • 102 Posts
  • 35 Reply Likes
Hi Basteagow,

This forum is only for quick questions, For config review and file sharing we would appreciate if a tac case can be opened. This will help us to look into the problem remotely and debug live.


Thanks
Jijo
Photo of basteagow

basteagow

  • 9 Posts
  • 3 Reply Likes
I opened case # 01074612 but was rejected due to not having a support contract.

Considering how many different combinations of key and certificate types I've tried (all of which match what the documentation claims is supported), I'm very confident that this is either a bug or something that should be better documented—and in either case, the certificate import code should at the very least be printing more useful, granular error messages.

If this feature was implemented well, I wouldn't be needing support in the first place. Could you guys make an exception to the support contract requirement and see if this works on your end?

Thanks very much in advance!
Photo of basteagow

basteagow

  • 9 Posts
  • 3 Reply Likes
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.
Photo of Jijo Panangat

Jijo Panangat, Employee

  • 102 Posts
  • 35 Reply Likes
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