nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

unknown

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.

Find more posts tagged with

Accepted answers

All comments

jijo_panangat

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

unknown

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.

jijo_panangat

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

unknown

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!

unknown

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:

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.
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.
FastIron devices are the only hardware on our network that doesn't support PKCS #8 private keys.
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.

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.

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.

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

Generate key in PKCS#1 format. Use the -traditional, see openssl-genrsa for more details.
```
openssl genrsa -traditional -out keyfile 2048
```

Export public key (not strictly necessary)

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

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

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

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