Skip to main content

10 Messages

 • 

250 Points

Tue, Jun 23, 2020 10:33 PM

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

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.

Responses

Employee

 • 

138 Messages

 • 

2.3K Points

4 months ago

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

10 Messages

 • 

250 Points

4 months ago

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.

Employee

 • 

138 Messages

 • 

2.3K Points

4 months ago

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

10 Messages

 • 

250 Points

4 months ago

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!

10 Messages

 • 

250 Points

4 months ago

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.

Employee

 • 

138 Messages

 • 

2.3K Points

4 months ago

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 


1 Message

 • 

82 Points

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.