cannot read PEM key file - no start line

[Liz Fall]

All,



I am getting the following with my client cert when trying to connect to an
SSL-enabled MongoDB:



2014-09-03T13:37:56.881-0500 ERROR: cannot read PEM key file:
/users/apps/tstlrn/u019807/DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem
error:0906D06C:PEM routines:PEM_read_bio:no start line



The cert file is the following:



• DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem
• WF Enterprise CA 02 certificate, signed by WF Root
• WF Root certificate





I was told by the support at MongoDB to do the following:



§ Copy the certificates into a text editor to ensure there is no whitespace

§ Ensure the beginning and end certificate statements are on there own line
and have the same number of '-' at each end.

§ Ensure each line has 64 chars (except the last line)



I have checked and verified that there is no whitespace. Also, the BEGIN
and END statements look correct. However, each line in the cert is 76 chars
in length, except for the last line. Should the lines be 64-characters
long?



Can someone please help me?



Thanks,

Liz





---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[Jeffrey Walton]

Post by Liz Fall
I am getting the following with my client cert when trying to connect to
/users/apps/tstlrn/u019807/DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem
error:0906D06C:PEM routines:PEM_read_bio:no start line
• DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem
• WF Enterprise CA 02 certificate, signed by WF Root
• WF Root certificate

You should probably post the certificate somewhere so others can examine it.

Post by Liz Fall
§ Copy the certificates into a text editor to ensure there is no
whitespace
§ Ensure the beginning and end certificate statements are on there own
line and have the same number of '-' at each end.
§ Ensure each line has 64 chars (except the last line)

I don't believe OpenSSL has these restrictions.

Are they MongoDB requirements?

Post by Liz Fall
I have checked and verified that there is no whitespace. Also, the BEGIN
and END statements look correct. However, each line in the cert is 76
chars in length, except for the last line. Should the lines be
64-characters long?

The following will tell you if the problem is with the certificate or lies
elsewhere.

openssl x509 -in ...bank.corp_mongo_wells.pem -inform PEM -text -noout

You can also try -inform DER if the certificate is ASN.1/DER encoded. If it
is, then convert it from DER to PEM.

If you can dump the certificate, then the certificate is probably OK and
the problem likely lies elsewhere.

Jeff

[Viktor Dukhovni]

Post by Liz Fall
I have checked and verified that there is no whitespace. Also, the BEGIN
and END statements look correct. However, each line in the cert is 76 chars
in length, except for the last line. Should the lines be 64-characters
long?

Yes. The OpenSSL base64 decoder limits input lines to 64 characters.

[Liz Fall]

Hi Viktor,

Thank you so much for your response.

Do I need to request for a specific certificate that will is base64?

Thanks,
Liz

-----Original Message-----
From: owner-openssl-users-MCmKBN63+***@public.gmane.org
[mailto:owner-openssl-users-MCmKBN63+***@public.gmane.org] On Behalf Of Viktor Dukhovni
Sent: Monday, September 08, 2014 5:42 AM
To: openssl-users-MCmKBN63+***@public.gmane.org
Subject: Re: cannot read PEM key file - no start line

Post by Liz Fall
I have checked and verified that there is no whitespace. Also, the
BEGIN and END statements look correct. However, each line in the cert
is 76 chars in length, except for the last line. Should the lines be
64-characters long?

Yes. The OpenSSL base64 decoder limits input lines to 64 characters.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Viktor Dukhovni]

Post by Liz Fall
Thank you so much for your response.
Do I need to request for a specific certificate that will is base64?

No, you can just re-wrap the base64 data you have to 64 characters
per line. There are two different 64's here. The size of the
base64 encoding alphabet (64 possible choices for each letter) and
the length of the PEM encoded line (64 such letters per line).

The file you have is already base64 encoded, but the line length
is not PEM compatible (PEM requires 64 characters per line). So
just rewrap the lines to use 64 chars on all but the last line.

Example: Same (random) base64 data wrapped to 76 characters per
line and 64 per line:

$ rand=$(mktemp /tmp/rand.XXXXXX)
$ openssl rand 1024 > $rand
$ echo; echo "76 per line:"
$ < $rand perl -MMIME::Base64 -e '
while (($n = read(STDIN, $buf, 57)) > 0) {
print encode_base64($buf);
}
'
$ echo; echo "64 per line:"
$ < $rand perl -MMIME::Base64 -e '
while (($n = read(STDIN, $buf, 48)) > 0) {
print encode_base64($buf);
}
'
$ rm -f $rand

76 per line:
KaKWCSfJmiuxlTinrD+dCQbsZkIb9ne5A1f3I1ZkFY6jmDkhC4lSmW+eRr61ANlYfh+TqSTcUHe9
6FBQtc0HiV2mPezaBkdK6gH61vKBQYY5mEryMeJ86K56UwAL+VXQzV6AQLY74Hnjs1sZuuUtL6ju
rWGkgwqdJ0j/a7ie0baqUls4jxXA6kRdfYL5v6A16R0g94I1NNVGNWL4uF9sWvfJZSHDoxg2RGZq
LwjOR9M2BPiFPeun22GnlibTK+jzIjB3j4f/FLJ+QdFVVVCUK0coWfJw33+F583G6YJIifUZC38j
cxH5hLcuvtwev+cpuLiAwMqT07CISVotkQvNxoLCPvVpD/43uTnxWvd0qBC0kJ/E99d0q2Ig3wtO
kdFZl1x0xhhw4MVHYDfQ5XPzIz3KRDVpDJI6YbeTltOdCY1Td2tMolJLIen7G7d13c2HQk9ouuKf
wo8rljcsu0GoHR7czAiqYUDgT+EAlVBIfov3kSj2R02zIZS0YEBZLVQM6LhOCD9zGOFxvxC+xYsj
+UfeMIj/kF+i7vXXnXosHyyqKIQxyFhoJdNqADtPfyWIEMW05cnijpWKdrnrvvFirEeQMnLIJemZ
EPxc57WTh9O/vuZDLGm90qa8FwfUkyLGf7bqVRWoFQJWRMGifQStx/qvasA5HvfaOC0yaRcqBFeo
uykVr8gM5uPldKUMA0zdsUPYjvto/ZUwshTEgHyA7T7Vinp9Mmn+HhzlGw80yQHfKytEVfaJFmUk
cStshPOGvMQCwLtOEX8ijt3XkKUZdbW3HYfOVCvrVwGY/ARznrMU5OyTedOgKcsElH+u2qiCTQYa
E+MrSYwYbX+1Vs9fbd8tGT/9qUwyRFNY7BULs5LMC4EePbpMvXT0YFlMhmqcGABBNzUPaDv1kWgP
wcOO+DuTuxTeZl2Z5WjrUzM4VcTd7wZ9mv3GOAE1iErBC/MqnaTjJNuoDsm874si3A3Pb7IbBRyz
021LN+64cXJ7Yrq+CNfP7jVUynthkfFBSMe5OA3Ep9uDblS5/8lvSKeh4zONxoVNJH79PQr7G4V2
jR/WjhlrOei+of89TIaCaSw22vMzXUiOpTpK7fvJQardMuThCnlYDnlgczxjbvYVJe7OOWcsR5En
f5Ccb5rC2E1IQHxn4xYpf7qrsPDJf4gGTkU8qTppHqnsqiSiFlpDZ5OWDr2xC9X6kObEeEw4gGiH
OcNnD8mCPQrNuksnDszFnUKnoY8s/ugj7YlbvgqOE1KNZeMl0Bi6lxsoLroIiciqBscqeNR9WU7C
EwWz0CEmWdTSh5eMqJPJqgAi8zY8njbCG9IUf7HfuXEf1ESvvTE7UNlKBmrRal3rAIKDIVJIAQ==

64 per line:
KaKWCSfJmiuxlTinrD+dCQbsZkIb9ne5A1f3I1ZkFY6jmDkhC4lSmW+eRr61ANlY
fh+TqSTcUHe96FBQtc0HiV2mPezaBkdK6gH61vKBQYY5mEryMeJ86K56UwAL+VXQ
zV6AQLY74Hnjs1sZuuUtL6jurWGkgwqdJ0j/a7ie0baqUls4jxXA6kRdfYL5v6A1
6R0g94I1NNVGNWL4uF9sWvfJZSHDoxg2RGZqLwjOR9M2BPiFPeun22GnlibTK+jz
IjB3j4f/FLJ+QdFVVVCUK0coWfJw33+F583G6YJIifUZC38jcxH5hLcuvtwev+cp
uLiAwMqT07CISVotkQvNxoLCPvVpD/43uTnxWvd0qBC0kJ/E99d0q2Ig3wtOkdFZ
l1x0xhhw4MVHYDfQ5XPzIz3KRDVpDJI6YbeTltOdCY1Td2tMolJLIen7G7d13c2H
Qk9ouuKfwo8rljcsu0GoHR7czAiqYUDgT+EAlVBIfov3kSj2R02zIZS0YEBZLVQM
6LhOCD9zGOFxvxC+xYsj+UfeMIj/kF+i7vXXnXosHyyqKIQxyFhoJdNqADtPfyWI
EMW05cnijpWKdrnrvvFirEeQMnLIJemZEPxc57WTh9O/vuZDLGm90qa8FwfUkyLG
f7bqVRWoFQJWRMGifQStx/qvasA5HvfaOC0yaRcqBFeouykVr8gM5uPldKUMA0zd
sUPYjvto/ZUwshTEgHyA7T7Vinp9Mmn+HhzlGw80yQHfKytEVfaJFmUkcStshPOG
vMQCwLtOEX8ijt3XkKUZdbW3HYfOVCvrVwGY/ARznrMU5OyTedOgKcsElH+u2qiC
TQYaE+MrSYwYbX+1Vs9fbd8tGT/9qUwyRFNY7BULs5LMC4EePbpMvXT0YFlMhmqc
GABBNzUPaDv1kWgPwcOO+DuTuxTeZl2Z5WjrUzM4VcTd7wZ9mv3GOAE1iErBC/Mq
naTjJNuoDsm874si3A3Pb7IbBRyz021LN+64cXJ7Yrq+CNfP7jVUynthkfFBSMe5
OA3Ep9uDblS5/8lvSKeh4zONxoVNJH79PQr7G4V2jR/WjhlrOei+of89TIaCaSw2
2vMzXUiOpTpK7fvJQardMuThCnlYDnlgczxjbvYVJe7OOWcsR5Enf5Ccb5rC2E1I
QHxn4xYpf7qrsPDJf4gGTkU8qTppHqnsqiSiFlpDZ5OWDr2xC9X6kObEeEw4gGiH
OcNnD8mCPQrNuksnDszFnUKnoY8s/ugj7YlbvgqOE1KNZeMl0Bi6lxsoLroIiciq
BscqeNR9WU7CEwWz0CEmWdTSh5eMqJPJqgAi8zY8njbCG9IUf7HfuXEf1ESvvTE7
UNlKBmrRal3rAIKDIVJIAQ==

[Liz Fall]

Hi Viktor,

Thanks for your response.

I also saw this response from -M. Would this be a problem also?

Cert file or key file? The error indicates that the client can't find the
private key.

Thank you,
Liz

-----Original Message-----
From: owner-openssl-users-MCmKBN63+***@public.gmane.org
[mailto:owner-openssl-users-MCmKBN63+***@public.gmane.org] On Behalf Of Viktor Dukhovni
Sent: Monday, September 08, 2014 5:20 PM
To: openssl-users-MCmKBN63+***@public.gmane.org
Subject: Re: cannot read PEM key file - no start line

Post by Liz Fall
Thank you so much for your response.
Do I need to request for a specific certificate that will is base64?

No, you can just re-wrap the base64 data you have to 64 characters per line.
There are two different 64's here. The size of the
base64 encoding alphabet (64 possible choices for each letter) and the
length of the PEM encoded line (64 such letters per line).

The file you have is already base64 encoded, but the line length is not PEM
compatible (PEM requires 64 characters per line). So just rewrap the lines
to use 64 chars on all but the last line.

Example: Same (random) base64 data wrapped to 76 characters per line and 64
per line:

$ rand=$(mktemp /tmp/rand.XXXXXX)
$ openssl rand 1024 > $rand
$ echo; echo "76 per line:"
$ < $rand perl -MMIME::Base64 -e '
while (($n = read(STDIN, $buf, 57)) > 0) {
print encode_base64($buf);
}
'
$ echo; echo "64 per line:"
$ < $rand perl -MMIME::Base64 -e '
while (($n = read(STDIN, $buf, 48)) > 0) {
print encode_base64($buf);
}
'
$ rm -f $rand

76 per line:
KaKWCSfJmiuxlTinrD+dCQbsZkIb9ne5A1f3I1ZkFY6jmDkhC4lSmW+eRr61ANlYfh+TqSTc
KaKWCSfJmiuxlTinrD+dCQbsZkIb9ne5A1f3I1ZkFY6jmDkhC4lSmW+eRr61ANlYfh+UHe9
6FBQtc0HiV2mPezaBkdK6gH61vKBQYY5mEryMeJ86K56UwAL+VXQzV6AQLY74Hnjs1sZuuUt
6FBQtc0HiV2mPezaBkdK6gH61vKBQYY5mEryMeJ86K56UwAL+L6ju
rWGkgwqdJ0j/a7ie0baqUls4jxXA6kRdfYL5v6A16R0g94I1NNVGNWL4uF9sWvfJZSHDoxg2RGZq
LwjOR9M2BPiFPeun22GnlibTK+jzIjB3j4f/FLJ+QdFVVVCUK0coWfJw33+F583G6YJIifUZ
LwjOR9M2BPiFPeun22GnlibTK+C38j
cxH5hLcuvtwev+cpuLiAwMqT07CISVotkQvNxoLCPvVpD/43uTnxWvd0qBC0kJ/E99d0q2Ig
cxH5hLcuvtwev+3wtO
kdFZl1x0xhhw4MVHYDfQ5XPzIz3KRDVpDJI6YbeTltOdCY1Td2tMolJLIen7G7d13c2HQk9ouuKf
wo8rljcsu0GoHR7czAiqYUDgT+EAlVBIfov3kSj2R02zIZS0YEBZLVQM6LhOCD9zGOFxvxC+xYsj
+UfeMIj/kF+i7vXXnXosHyyqKIQxyFhoJdNqADtPfyWIEMW05cnijpWKdrnrvvFirEeQMnLI
+JemZ
EPxc57WTh9O/vuZDLGm90qa8FwfUkyLGf7bqVRWoFQJWRMGifQStx/qvasA5HvfaOC0yaRcqBFeo
uykVr8gM5uPldKUMA0zdsUPYjvto/ZUwshTEgHyA7T7Vinp9Mmn+HhzlGw80yQHfKytEVfaJFmUk
cStshPOGvMQCwLtOEX8ijt3XkKUZdbW3HYfOVCvrVwGY/ARznrMU5OyTedOgKcsElH+u2qiCTQYa
E+MrSYwYbX+1Vs9fbd8tGT/9qUwyRFNY7BULs5LMC4EePbpMvXT0YFlMhmqcGABBNzUPaDv1
E+MrSYwYbX+kWgP
wcOO+DuTuxTeZl2Z5WjrUzM4VcTd7wZ9mv3GOAE1iErBC/MqnaTjJNuoDsm874si3A3Pb7Ib
wcOO+BRyz
021LN+64cXJ7Yrq+CNfP7jVUynthkfFBSMe5OA3Ep9uDblS5/8lvSKeh4zONxoVNJH79PQr7
021LN+64cXJ7Yrq+G4V2
jR/WjhlrOei+of89TIaCaSw22vMzXUiOpTpK7fvJQardMuThCnlYDnlgczxjbvYVJe7OOWcsR5En
f5Ccb5rC2E1IQHxn4xYpf7qrsPDJf4gGTkU8qTppHqnsqiSiFlpDZ5OWDr2xC9X6kObEeEw4gGiH
OcNnD8mCPQrNuksnDszFnUKnoY8s/ugj7YlbvgqOE1KNZeMl0Bi6lxsoLroIiciqBscqeNR9WU7C
EwWz0CEmWdTSh5eMqJPJqgAi8zY8njbCG9IUf7HfuXEf1ESvvTE7UNlKBmrRal3rAIKDIVJIAQ==

64 per line:
KaKWCSfJmiuxlTinrD+dCQbsZkIb9ne5A1f3I1ZkFY6jmDkhC4lSmW+eRr61ANlY
fh+TqSTcUHe96FBQtc0HiV2mPezaBkdK6gH61vKBQYY5mEryMeJ86K56UwAL+VXQ
zV6AQLY74Hnjs1sZuuUtL6jurWGkgwqdJ0j/a7ie0baqUls4jxXA6kRdfYL5v6A1
6R0g94I1NNVGNWL4uF9sWvfJZSHDoxg2RGZqLwjOR9M2BPiFPeun22GnlibTK+jz
IjB3j4f/FLJ+QdFVVVCUK0coWfJw33+F583G6YJIifUZC38jcxH5hLcuvtwev+cp
uLiAwMqT07CISVotkQvNxoLCPvVpD/43uTnxWvd0qBC0kJ/E99d0q2Ig3wtOkdFZ
l1x0xhhw4MVHYDfQ5XPzIz3KRDVpDJI6YbeTltOdCY1Td2tMolJLIen7G7d13c2H
Qk9ouuKfwo8rljcsu0GoHR7czAiqYUDgT+EAlVBIfov3kSj2R02zIZS0YEBZLVQM
6LhOCD9zGOFxvxC+xYsj+UfeMIj/kF+i7vXXnXosHyyqKIQxyFhoJdNqADtPfyWI
EMW05cnijpWKdrnrvvFirEeQMnLIJemZEPxc57WTh9O/vuZDLGm90qa8FwfUkyLG
f7bqVRWoFQJWRMGifQStx/qvasA5HvfaOC0yaRcqBFeouykVr8gM5uPldKUMA0zd
sUPYjvto/ZUwshTEgHyA7T7Vinp9Mmn+HhzlGw80yQHfKytEVfaJFmUkcStshPOG
vMQCwLtOEX8ijt3XkKUZdbW3HYfOVCvrVwGY/ARznrMU5OyTedOgKcsElH+u2qiC
TQYaE+MrSYwYbX+1Vs9fbd8tGT/9qUwyRFNY7BULs5LMC4EePbpMvXT0YFlMhmqc
GABBNzUPaDv1kWgPwcOO+DuTuxTeZl2Z5WjrUzM4VcTd7wZ9mv3GOAE1iErBC/Mq
naTjJNuoDsm874si3A3Pb7IbBRyz021LN+64cXJ7Yrq+CNfP7jVUynthkfFBSMe5
OA3Ep9uDblS5/8lvSKeh4zONxoVNJH79PQr7G4V2jR/WjhlrOei+of89TIaCaSw2
2vMzXUiOpTpK7fvJQardMuThCnlYDnlgczxjbvYVJe7OOWcsR5Enf5Ccb5rC2E1I
QHxn4xYpf7qrsPDJf4gGTkU8qTppHqnsqiSiFlpDZ5OWDr2xC9X6kObEeEw4gGiH
OcNnD8mCPQrNuksnDszFnUKnoY8s/ugj7YlbvgqOE1KNZeMl0Bi6lxsoLroIiciq
BscqeNR9WU7CEwWz0CEmWdTSh5eMqJPJqgAi8zY8njbCG9IUf7HfuXEf1ESvvTE7
UNlKBmrRal3rAIKDIVJIAQ==
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Liz Fall]

Thanks, Viktor.

I have tried to rewrap this cert to 64 per line, but am having difficulties.
I tried to do it in two steps with the first cert and then the second cert,
but each time, I am not getting all of the characters. Can you please help?

Thanks,
Liz

-----Original Message-----
From: owner-openssl-users-MCmKBN63+***@public.gmane.org
[mailto:owner-openssl-users-MCmKBN63+***@public.gmane.org] On Behalf Of Viktor Dukhovni
Sent: Monday, September 08, 2014 5:20 PM
To: openssl-users-MCmKBN63+***@public.gmane.org
Subject: Re: cannot read PEM key file - no start line

Post by Liz Fall
Thank you so much for your response.
Do I need to request for a specific certificate that will is base64?

No, you can just re-wrap the base64 data you have to 64 characters per line.
There are two different 64's here. The size of the
base64 encoding alphabet (64 possible choices for each letter) and the
length of the PEM encoded line (64 such letters per line).

The file you have is already base64 encoded, but the line length is not PEM
compatible (PEM requires 64 characters per line). So just rewrap the lines
to use 64 chars on all but the last line.

Example: Same (random) base64 data wrapped to 76 characters per line and 64
per line:

$ rand=$(mktemp /tmp/rand.XXXXXX)
$ openssl rand 1024 > $rand
$ echo; echo "76 per line:"
$ < $rand perl -MMIME::Base64 -e '
while (($n = read(STDIN, $buf, 57)) > 0) {
print encode_base64($buf);
}
'
$ echo; echo "64 per line:"
$ < $rand perl -MMIME::Base64 -e '
while (($n = read(STDIN, $buf, 48)) > 0) {
print encode_base64($buf);
}
'
$ rm -f $rand

76 per line:
KaKWCSfJmiuxlTinrD+dCQbsZkIb9ne5A1f3I1ZkFY6jmDkhC4lSmW+eRr61ANlYfh+TqSTc
KaKWCSfJmiuxlTinrD+dCQbsZkIb9ne5A1f3I1ZkFY6jmDkhC4lSmW+eRr61ANlYfh+UHe9
6FBQtc0HiV2mPezaBkdK6gH61vKBQYY5mEryMeJ86K56UwAL+VXQzV6AQLY74Hnjs1sZuuUt
6FBQtc0HiV2mPezaBkdK6gH61vKBQYY5mEryMeJ86K56UwAL+L6ju
rWGkgwqdJ0j/a7ie0baqUls4jxXA6kRdfYL5v6A16R0g94I1NNVGNWL4uF9sWvfJZSHDoxg2RGZq
LwjOR9M2BPiFPeun22GnlibTK+jzIjB3j4f/FLJ+QdFVVVCUK0coWfJw33+F583G6YJIifUZ
LwjOR9M2BPiFPeun22GnlibTK+C38j
cxH5hLcuvtwev+cpuLiAwMqT07CISVotkQvNxoLCPvVpD/43uTnxWvd0qBC0kJ/E99d0q2Ig
cxH5hLcuvtwev+3wtO
kdFZl1x0xhhw4MVHYDfQ5XPzIz3KRDVpDJI6YbeTltOdCY1Td2tMolJLIen7G7d13c2HQk9ouuKf
wo8rljcsu0GoHR7czAiqYUDgT+EAlVBIfov3kSj2R02zIZS0YEBZLVQM6LhOCD9zGOFxvxC+xYsj
+UfeMIj/kF+i7vXXnXosHyyqKIQxyFhoJdNqADtPfyWIEMW05cnijpWKdrnrvvFirEeQMnLI
+JemZ
EPxc57WTh9O/vuZDLGm90qa8FwfUkyLGf7bqVRWoFQJWRMGifQStx/qvasA5HvfaOC0yaRcqBFeo
uykVr8gM5uPldKUMA0zdsUPYjvto/ZUwshTEgHyA7T7Vinp9Mmn+HhzlGw80yQHfKytEVfaJFmUk
cStshPOGvMQCwLtOEX8ijt3XkKUZdbW3HYfOVCvrVwGY/ARznrMU5OyTedOgKcsElH+u2qiCTQYa
E+MrSYwYbX+1Vs9fbd8tGT/9qUwyRFNY7BULs5LMC4EePbpMvXT0YFlMhmqcGABBNzUPaDv1
E+MrSYwYbX+kWgP
wcOO+DuTuxTeZl2Z5WjrUzM4VcTd7wZ9mv3GOAE1iErBC/MqnaTjJNuoDsm874si3A3Pb7Ib
wcOO+BRyz
021LN+64cXJ7Yrq+CNfP7jVUynthkfFBSMe5OA3Ep9uDblS5/8lvSKeh4zONxoVNJH79PQr7
021LN+64cXJ7Yrq+G4V2
jR/WjhlrOei+of89TIaCaSw22vMzXUiOpTpK7fvJQardMuThCnlYDnlgczxjbvYVJe7OOWcsR5En
f5Ccb5rC2E1IQHxn4xYpf7qrsPDJf4gGTkU8qTppHqnsqiSiFlpDZ5OWDr2xC9X6kObEeEw4gGiH
OcNnD8mCPQrNuksnDszFnUKnoY8s/ugj7YlbvgqOE1KNZeMl0Bi6lxsoLroIiciqBscqeNR9WU7C
EwWz0CEmWdTSh5eMqJPJqgAi8zY8njbCG9IUf7HfuXEf1ESvvTE7UNlKBmrRal3rAIKDIVJIAQ==

64 per line:
KaKWCSfJmiuxlTinrD+dCQbsZkIb9ne5A1f3I1ZkFY6jmDkhC4lSmW+eRr61ANlY
fh+TqSTcUHe96FBQtc0HiV2mPezaBkdK6gH61vKBQYY5mEryMeJ86K56UwAL+VXQ
zV6AQLY74Hnjs1sZuuUtL6jurWGkgwqdJ0j/a7ie0baqUls4jxXA6kRdfYL5v6A1
6R0g94I1NNVGNWL4uF9sWvfJZSHDoxg2RGZqLwjOR9M2BPiFPeun22GnlibTK+jz
IjB3j4f/FLJ+QdFVVVCUK0coWfJw33+F583G6YJIifUZC38jcxH5hLcuvtwev+cp
uLiAwMqT07CISVotkQvNxoLCPvVpD/43uTnxWvd0qBC0kJ/E99d0q2Ig3wtOkdFZ
l1x0xhhw4MVHYDfQ5XPzIz3KRDVpDJI6YbeTltOdCY1Td2tMolJLIen7G7d13c2H
Qk9ouuKfwo8rljcsu0GoHR7czAiqYUDgT+EAlVBIfov3kSj2R02zIZS0YEBZLVQM
6LhOCD9zGOFxvxC+xYsj+UfeMIj/kF+i7vXXnXosHyyqKIQxyFhoJdNqADtPfyWI
EMW05cnijpWKdrnrvvFirEeQMnLIJemZEPxc57WTh9O/vuZDLGm90qa8FwfUkyLG
f7bqVRWoFQJWRMGifQStx/qvasA5HvfaOC0yaRcqBFeouykVr8gM5uPldKUMA0zd
sUPYjvto/ZUwshTEgHyA7T7Vinp9Mmn+HhzlGw80yQHfKytEVfaJFmUkcStshPOG
vMQCwLtOEX8ijt3XkKUZdbW3HYfOVCvrVwGY/ARznrMU5OyTedOgKcsElH+u2qiC
TQYaE+MrSYwYbX+1Vs9fbd8tGT/9qUwyRFNY7BULs5LMC4EePbpMvXT0YFlMhmqc
GABBNzUPaDv1kWgPwcOO+DuTuxTeZl2Z5WjrUzM4VcTd7wZ9mv3GOAE1iErBC/Mq
naTjJNuoDsm874si3A3Pb7IbBRyz021LN+64cXJ7Yrq+CNfP7jVUynthkfFBSMe5
OA3Ep9uDblS5/8lvSKeh4zONxoVNJH79PQr7G4V2jR/WjhlrOei+of89TIaCaSw2
2vMzXUiOpTpK7fvJQardMuThCnlYDnlgczxjbvYVJe7OOWcsR5Enf5Ccb5rC2E1I
QHxn4xYpf7qrsPDJf4gGTkU8qTppHqnsqiSiFlpDZ5OWDr2xC9X6kObEeEw4gGiH
OcNnD8mCPQrNuksnDszFnUKnoY8s/ugj7YlbvgqOE1KNZeMl0Bi6lxsoLroIiciq
BscqeNR9WU7CEwWz0CEmWdTSh5eMqJPJqgAi8zY8njbCG9IUf7HfuXEf1ESvvTE7
UNlKBmrRal3rAIKDIVJIAQ==
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[Dave Thompson]

Sent: Monday, September 08, 2014 08:42

Post by Liz Fall
I have checked and verified that there is no whitespace. Also, the BEGIN
and END statements look correct. However, each line in the cert is 76

chars

Post by Liz Fall
in length, except for the last line. Should the lines be 64-characters
long?

Yes. The OpenSSL base64 decoder limits input lines to 64 characters.

Nope. The encoder writes 64 (the original PEM spec), but the decoder
will accept up to 76 (the less-old MIME spec). As one case I hit often,
Java keytool -exportcert writes 76 and openssl reads it just fine.

And the error here is "no start line". *On Windows* that often occurs
when Windows editors treat text files as Unicode/UTF-8 with an
invisible "BOM" (Byte Order Mark) at the beginning of the first line.
Try prepending a semantically-meaningless comment line like:

Hello! This is my Key!! Rah Rah Go Key Go!!
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIAqD7NQvpg74v7Pik4rAIfk/BIQlQa1fbM9BKkHOkKJBoAoGCCqGSM49
AwEHoUQDQgAE/BR1oMSfz4WgklW7t83E0xClrBh0md1Ata8rsPq8VAsB1WDXPXwk
T7WbcXlsyxuyOb7ok8F544xmr+pKreWbHw==
-----END EC PRIVATE KEY-----


______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Liz Fall]

Hi Dave,

Thanks for your response. I am running this on Linux.

This is what my cert looks like below: What are you saying I should do?
Thanks for the clarification. Liz

-----BEGIN CERTIFICATE-----
MIIFrDCCBJSgAwIBAgIEQLJp/DANBgkqhkiG9w0BAQUFADCBgjELMAkGA1UEBhMCVVMxFDASBgNV
BAoTC1dlbGxzIEZhcmdvMSwwKgYDVQQLEyNXZWxscyBGYXJnbyBDZXJ0aWZpY2F0aW9uIEF1dGhv
cml0eTEvMC0GA1UEAxMmV2VsbHMgRmFyZ28gUm9vdCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcN
MDkwNTI4MTgxNzI2WhcNMTkwNTI4MTgxNzI2WjB4MQswCQYDVQQGEwJVUzEUMBIGA1UEChMLV2Vs
bHMgRmFyZ28xLDAqBgNVBAsTI1dlbGxzIEZhcmdvIENlcnRpZmljYXRlIEF1dGhvcml0aWVzMSUw
IwYDVQQDExxXZWxscyBGYXJnbyBFbnRlcnByaXNlIENBIDAyMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAm1mEVgXlHHbd4DrKFIROTf6Q5JwzJEtjFiWN4lQsEvKeVN1p7/ua16c0gFhi
zQvuD002pttUG7Tn6uUonUYxJajD2TnykAQu1m5Ks1gisNgYCGzH8tluKeWYANppSRt5F1Is3Yts
NOGiYtVFnZf3FejOzVWkhnT5rYXjTf9Osu5KK1Jh7NywbFU5P2ytC4h/M9xnlHuCjy7RBmN956iG
7Eb+BBrvo7ZfTfzWuFzmvficKovoDbZOloLHHsRzj2iQ2euY+xW/g+Zn1lHPQCZfTdLgPUcnV7qp
P+1fRVy5hNLQTw3nBrNa5RLIZK8RBpY6kig4wWhyNKP+9Ssc2m34lQIDAQABo4ICMTCCAi0wDwYD
VR0TAQH/BAUwAwEB/zCBgwYDVR0gBHwwejA7BgtghkgBhvt7g3QAADAsMCoGCCsGAQUFBwIBFh5o
dHRwOi8vd3d3LndlbGxzZmFyZ28uY29tL2Nwcy8wOwYLYIZIAYb7e4N0AAEwLDAqBggrBgEFBQcC
ARYeaHR0cDovL3d3dy53ZWxsc2ZhcmdvLmNvbS9jcHMvMHcGCCsGAQUFBwEBBGswaTAwBggrBgEF
BQcwAYYkaHR0cDovL29jc3Atcm9vdC5wa2kud2VsbHNmYXJnby5jb20vMDUGCCsGAQUFBzAChilo
dHRwOi8vY3JsLnBraS53ZWxsc2ZhcmdvLmNvbS93Zl9yb290LmNydDAOBgNVHQ8BAf8EBAMCAfYw
gbIGA1UdIwSBqjCBp4AUFK8Y973m52vjWvrqUe/+1FpxOcChgYikgYUwgYIxCzAJBgNVBAYTAlVT
MRQwEgYDVQQKEwtXZWxscyBGYXJnbzEsMCoGA1UECxMjV2VsbHMgRmFyZ28gQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkxLzAtBgNVBAMTJldlbGxzIEZhcmdvIFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9y
aXR5ggQ55JeeMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly9jcmwucGtpLndlbGxzZmFyZ28uY29t
L3Jvb3QuY3JsMB0GA1UdDgQWBBTEq0W2OgsBHGJcyj/H480vMMRX1zANBgkqhkiG9w0BAQUFAAOC
AQEALUIw6yFNj7mrTSIuqtT6rsAXgKApylI3HtepbWa6qxEmmDDjCAaOxXZKShTxBQa6qSpYFg0K
FxqKsNiot8CAEMxXcapr5OLwytTFvnDSRa9H+mlLT6jpZi8C3fbqEvbVeh7NjT4oj8fNbsf13UgN
0xxlgiez47locWVADdYP/RucG31o+8OqJaZ/+AWsc+B6LoQ9jaYlYaiXXERQopLS8dxTeGp8pvmd
YK4ghHG/AwLW0fEcaqQOqrBcf8A+3/RQYEdJ62vZ8Q9T6HwbdPr0zToqeVM5i+DgLjy2fq1eEp6a
5In0N78tkgEr8NPlpPgb93C6T8kNYioQY20dNklqLQ==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIID5TCCAs2gAwIBAgIEOeSXnjANBgkqhkiG9w0BAQUFADCBgjELMAkGA1UEBhMCVVMxFDASBgNV
BAoTC1dlbGxzIEZhcmdvMSwwKgYDVQQLEyNXZWxscyBGYXJnbyBDZXJ0aWZpY2F0aW9uIEF1dGhv
cml0eTEvMC0GA1UEAxMmV2VsbHMgRmFyZ28gUm9vdCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcN
MDAxMDExMTY0MTI4WhcNMjEwMTE0MTY0MTI4WjCBgjELMAkGA1UEBhMCVVMxFDASBgNVBAoTC1dl
bGxzIEZhcmdvMSwwKgYDVQQLEyNXZWxscyBGYXJnbyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEv
MC0GA1UEAxMmV2VsbHMgRmFyZ28gUm9vdCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDVqDM7Jvk0/82bfuUER84A4n135zHCLielTWi5MbqNQ1mX
x3Oqfz1cQJ4F5aHiidlMuD+b+Qy0yGIZLEWukR5zcUHESxP9cMIlrCL1dQu3U+SlK93OvRw6esP3
E48mVJwWa2uv+9iWsWCaSOAlIiR5NM4OJgALTqv9i86C1y8IcGjBqAr5dE8Hq6T54oN+J3N0Prj5
OEL8pahbSCOz6+MlsoCultQKnMJ4msZoGK43YjdeUXWoWGPAUe5AeH6orxqg4bB4nVCMe+ez/I4j
sNtlAHCEAQgAFG5Uhpq6zPk3EPbg3oQtnaSFN9OH4xXQwReQfhkhahKpdv0SAulPIV4XAgMBAAGj
YTBfMA8GA1UdEwEB/wQFMAMBAf8wTAYDVR0gBEUwQzBBBgtghkgBhvt7hwcBCzAyMDAGCCsGAQUF
BwIBFiRodHRwOi8vd3d3LndlbGxzZmFyZ28uY29tL2NlcnRwb2xpY3kwDQYJKoZIhvcNAQEFBQAD
ggEBANIn3ZwKdyu7IvICtUpKkfnRLb7kuxpo7w6kAOnu5+/u9vnldKTC2FJYxHT7zmu1Oyl5GFrv
m+0fazbuSCUlFLZWohDo7qd/0D+j0MNdJu4HzMPBJCGHHt8qElNvQRbn7a6U+oxy+hNH8Dx+rn0R
OhPs7fpvcmR7nX1/Jv16+yWt6j4pf0zjAFcysLPp7VMX2YuyFA4w6OXVE8Zkr8QA1dhYJPz1j+zx
x32l2w8n0cbyQIjmH/ZhqPRCyLk306m+LFZ4wnKbWV01QIroTmMatukgalHizqSQ33ZwmVxwQ023
tqcZZE6St8WRPH9IFmV7Fv3L/PvZ1dZPIWU7Sn9Ho/s=
-----END CERTIFICATE-----

-----Original Message-----
From: owner-openssl-users-MCmKBN63+***@public.gmane.org
[mailto:owner-openssl-users-MCmKBN63+***@public.gmane.org] On Behalf Of Dave Thompson
Sent: Monday, September 08, 2014 7:29 PM
To: openssl-users-MCmKBN63+***@public.gmane.org
Subject: RE: cannot read PEM key file - no start line

Sent: Monday, September 08, 2014 08:42

Post by Liz Fall
I have checked and verified that there is no whitespace. Also, the BEGIN
and END statements look correct. However, each line in the cert is 76

chars

Post by Liz Fall
in length, except for the last line. Should the lines be
64-characters long?

Yes. The OpenSSL base64 decoder limits input lines to 64 characters.

Nope. The encoder writes 64 (the original PEM spec), but the decoder will
accept up to 76 (the less-old MIME spec). As one case I hit often, Java
keytool -exportcert writes 76 and openssl reads it just fine.

And the error here is "no start line". *On Windows* that often occurs when
Windows editors treat text files as Unicode/UTF-8 with an invisible "BOM"
(Byte Order Mark) at the beginning of the first line.
Try prepending a semantically-meaningless comment line like:

Hello! This is my Key!! Rah Rah Go Key Go!!
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIAqD7NQvpg74v7Pik4rAIfk/BIQlQa1fbM9BKkHOkKJBoAoGCCqGSM49
AwEHoUQDQgAE/BR1oMSfz4WgklW7t83E0xClrBh0md1Ata8rsPq8VAsB1WDXPXwk
T7WbcXlsyxuyOb7ok8F544xmr+pKreWbHw==
-----END EC PRIVATE KEY-----


______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Viktor Dukhovni]

Post by Liz Fall
This is what my cert looks like below: What are you saying I should do?
Thanks for the clarification.

These are the certificates for an intermediate CA and the issuing root
CA. Generally, you'd append these to a certificate file with the
server certificate as the first entry, and a corresponding private
key in some other (not world-readable) file.

subject= /C=US/O=Wells Fargo/OU=Wells Fargo Certificate Authorities/CN=Wells Fargo Enterprise CA 02
issuer= /C=US/O=Wells Fargo/OU=Wells Fargo Certification Authority/CN=Wells Fargo Root Certificate Authority
notBefore=May 28 18:17:26 2009 GMT
notAfter=May 28 18:17:26 2019 GMT
SHA1 Fingerprint=DD:B1:96:37:D9:9D:EC:8F:05:A2:B1:38:BC:11:D4:AF:ED:0A:BE:39
-----BEGIN CERTIFICATE-----
MIIFrDCCBJSgAwIBAgIEQLJp/DANBgkqhkiG9w0BAQUFADCBgjELMAkGA1UEBhMC
VVMxFDASBgNVBAoTC1dlbGxzIEZhcmdvMSwwKgYDVQQLEyNXZWxscyBGYXJnbyBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEvMC0GA1UEAxMmV2VsbHMgRmFyZ28gUm9v
dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDkwNTI4MTgxNzI2WhcNMTkwNTI4
MTgxNzI2WjB4MQswCQYDVQQGEwJVUzEUMBIGA1UEChMLV2VsbHMgRmFyZ28xLDAq
BgNVBAsTI1dlbGxzIEZhcmdvIENlcnRpZmljYXRlIEF1dGhvcml0aWVzMSUwIwYD
VQQDExxXZWxscyBGYXJnbyBFbnRlcnByaXNlIENBIDAyMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAm1mEVgXlHHbd4DrKFIROTf6Q5JwzJEtjFiWN4lQs
EvKeVN1p7/ua16c0gFhizQvuD002pttUG7Tn6uUonUYxJajD2TnykAQu1m5Ks1gi
sNgYCGzH8tluKeWYANppSRt5F1Is3YtsNOGiYtVFnZf3FejOzVWkhnT5rYXjTf9O
su5KK1Jh7NywbFU5P2ytC4h/M9xnlHuCjy7RBmN956iG7Eb+BBrvo7ZfTfzWuFzm
vficKovoDbZOloLHHsRzj2iQ2euY+xW/g+Zn1lHPQCZfTdLgPUcnV7qpP+1fRVy5
hNLQTw3nBrNa5RLIZK8RBpY6kig4wWhyNKP+9Ssc2m34lQIDAQABo4ICMTCCAi0w
DwYDVR0TAQH/BAUwAwEB/zCBgwYDVR0gBHwwejA7BgtghkgBhvt7g3QAADAsMCoG
CCsGAQUFBwIBFh5odHRwOi8vd3d3LndlbGxzZmFyZ28uY29tL2Nwcy8wOwYLYIZI
AYb7e4N0AAEwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy53ZWxsc2ZhcmdvLmNv
bS9jcHMvMHcGCCsGAQUFBwEBBGswaTAwBggrBgEFBQcwAYYkaHR0cDovL29jc3At
cm9vdC5wa2kud2VsbHNmYXJnby5jb20vMDUGCCsGAQUFBzAChilodHRwOi8vY3Js
LnBraS53ZWxsc2ZhcmdvLmNvbS93Zl9yb290LmNydDAOBgNVHQ8BAf8EBAMCAfYw
gbIGA1UdIwSBqjCBp4AUFK8Y973m52vjWvrqUe/+1FpxOcChgYikgYUwgYIxCzAJ
BgNVBAYTAlVTMRQwEgYDVQQKEwtXZWxscyBGYXJnbzEsMCoGA1UECxMjV2VsbHMg
RmFyZ28gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxLzAtBgNVBAMTJldlbGxzIEZh
cmdvIFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5ggQ55JeeMDcGA1UdHwQwMC4w
LKAqoCiGJmh0dHA6Ly9jcmwucGtpLndlbGxzZmFyZ28uY29tL3Jvb3QuY3JsMB0G
A1UdDgQWBBTEq0W2OgsBHGJcyj/H480vMMRX1zANBgkqhkiG9w0BAQUFAAOCAQEA
LUIw6yFNj7mrTSIuqtT6rsAXgKApylI3HtepbWa6qxEmmDDjCAaOxXZKShTxBQa6
qSpYFg0KFxqKsNiot8CAEMxXcapr5OLwytTFvnDSRa9H+mlLT6jpZi8C3fbqEvbV
eh7NjT4oj8fNbsf13UgN0xxlgiez47locWVADdYP/RucG31o+8OqJaZ/+AWsc+B6
LoQ9jaYlYaiXXERQopLS8dxTeGp8pvmdYK4ghHG/AwLW0fEcaqQOqrBcf8A+3/RQ
YEdJ62vZ8Q9T6HwbdPr0zToqeVM5i+DgLjy2fq1eEp6a5In0N78tkgEr8NPlpPgb
93C6T8kNYioQY20dNklqLQ==
-----END CERTIFICATE-----

subject= /C=US/O=Wells Fargo/OU=Wells Fargo Certification Authority/CN=Wells Fargo Root Certificate Authority
issuer= /C=US/O=Wells Fargo/OU=Wells Fargo Certification Authority/CN=Wells Fargo Root Certificate Authority
notBefore=Oct 11 16:41:28 2000 GMT
notAfter=Jan 14 16:41:28 2021 GMT
SHA1 Fingerprint=93:E6:AB:22:03:03:B5:23:28:DC:DA:56:9E:BA:E4:D1:D1:CC:FB:65
-----BEGIN CERTIFICATE-----
MIID5TCCAs2gAwIBAgIEOeSXnjANBgkqhkiG9w0BAQUFADCBgjELMAkGA1UEBhMC
VVMxFDASBgNVBAoTC1dlbGxzIEZhcmdvMSwwKgYDVQQLEyNXZWxscyBGYXJnbyBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEvMC0GA1UEAxMmV2VsbHMgRmFyZ28gUm9v
dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDAxMDExMTY0MTI4WhcNMjEwMTE0
MTY0MTI4WjCBgjELMAkGA1UEBhMCVVMxFDASBgNVBAoTC1dlbGxzIEZhcmdvMSww
KgYDVQQLEyNXZWxscyBGYXJnbyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEvMC0G
A1UEAxMmV2VsbHMgRmFyZ28gUm9vdCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDVqDM7Jvk0/82bfuUER84A4n13
5zHCLielTWi5MbqNQ1mXx3Oqfz1cQJ4F5aHiidlMuD+b+Qy0yGIZLEWukR5zcUHE
SxP9cMIlrCL1dQu3U+SlK93OvRw6esP3E48mVJwWa2uv+9iWsWCaSOAlIiR5NM4O
JgALTqv9i86C1y8IcGjBqAr5dE8Hq6T54oN+J3N0Prj5OEL8pahbSCOz6+MlsoCu
ltQKnMJ4msZoGK43YjdeUXWoWGPAUe5AeH6orxqg4bB4nVCMe+ez/I4jsNtlAHCE
AQgAFG5Uhpq6zPk3EPbg3oQtnaSFN9OH4xXQwReQfhkhahKpdv0SAulPIV4XAgMB
AAGjYTBfMA8GA1UdEwEB/wQFMAMBAf8wTAYDVR0gBEUwQzBBBgtghkgBhvt7hwcB
CzAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3LndlbGxzZmFyZ28uY29tL2NlcnRw
b2xpY3kwDQYJKoZIhvcNAQEFBQADggEBANIn3ZwKdyu7IvICtUpKkfnRLb7kuxpo
7w6kAOnu5+/u9vnldKTC2FJYxHT7zmu1Oyl5GFrvm+0fazbuSCUlFLZWohDo7qd/
0D+j0MNdJu4HzMPBJCGHHt8qElNvQRbn7a6U+oxy+hNH8Dx+rn0ROhPs7fpvcmR7
nX1/Jv16+yWt6j4pf0zjAFcysLPp7VMX2YuyFA4w6OXVE8Zkr8QA1dhYJPz1j+zx
x32l2w8n0cbyQIjmH/ZhqPRCyLk306m+LFZ4wnKbWV01QIroTmMatukgalHizqSQ
33ZwmVxwQ023tqcZZE6St8WRPH9IFmV7Fv3L/PvZ1dZPIWU7Sn9Ho/s=
-----END CERTIFICATE-----

[Liz Fall]

Viktor and all:

Thanks for your response.

I am trying to connect to a MongoDB SSL-enable database. This is the API:

#include "mongo/util/net/ssl_options.h"
#include "mongo/client/init.h"

int main() {
sslGlobalParams.sslMode.store(SSLGlobalParams::SSLMode_requireSSL);

// only really need a PEM on the server side
mongo::sslGlobalParams.sslPEMKeyFile = "<path/to/keyfile.pem>";

mongo::Status status = mongo::client::initialize();

if (!status.isOK())
::abort();

DBClientConnection c;
c.connect("hostname.whatever.com"); // outgoing connections are SSL
}

My question to MongoDB support was: From the code above, the comment states
that there is only a need of a PEM on the server side. What identifies the
"key store" on the C++ client server? Is as key store not required on the
C++ linux server where my application is running?

MongoDB support response was: That is correct. For encrypted communications
only the MongoDB server needs a PEM file.

I am just not sure what I am supposed to be providing as far as the
sslPEMKeyFile. I have these certificates:

. DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_server.pem
. private key of DTCD9C3B2F42757.ent.wfb.bank.corp machine
. certificate for DTCD9C3B2F42757.ent.wfb.bank.corp, signed by WF
Enterprise CA 02

. DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem
. WF Enterprise CA 02 certificate, signed by WF Root
. WF Root certificate


Can someone please help clarify this?

Thanks,
Liz

-----Original Message-----
From: owner-openssl-users-MCmKBN63+***@public.gmane.org
[mailto:owner-openssl-users-MCmKBN63+***@public.gmane.org] On Behalf Of Viktor Dukhovni
Sent: Monday, September 08, 2014 7:54 PM
To: openssl-users-MCmKBN63+***@public.gmane.org
Subject: Re: cannot read PEM key file - no start line

Post by Liz Fall
This is what my cert looks like below: What are you saying I should do?
Thanks for the clarification.

These are the certificates for an intermediate CA and the issuing root CA.
Generally, you'd append these to a certificate file with the server
certificate as the first entry, and a corresponding private key in some
other (not world-readable) file.

subject= /C=US/O=Wells Fargo/OU=Wells Fargo Certificate Authorities/CN=Wells
Fargo Enterprise CA 02 issuer= /C=US/O=Wells Fargo/OU=Wells Fargo
Certification Authority/CN=Wells Fargo Root Certificate Authority
notBefore=May 28 18:17:26 2009 GMT notAfter=May 28 18:17:26 2019 GMT
SHA1 Fingerprint=DD:B1:96:37:D9:9D:EC:8F:05:A2:B1:38:BC:11:D4:AF:ED:0A:BE:39
-----BEGIN CERTIFICATE-----
MIIFrDCCBJSgAwIBAgIEQLJp/DANBgkqhkiG9w0BAQUFADCBgjELMAkGA1UEBhMC
VVMxFDASBgNVBAoTC1dlbGxzIEZhcmdvMSwwKgYDVQQLEyNXZWxscyBGYXJnbyBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEvMC0GA1UEAxMmV2VsbHMgRmFyZ28gUm9v
dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDkwNTI4MTgxNzI2WhcNMTkwNTI4
MTgxNzI2WjB4MQswCQYDVQQGEwJVUzEUMBIGA1UEChMLV2VsbHMgRmFyZ28xLDAq
BgNVBAsTI1dlbGxzIEZhcmdvIENlcnRpZmljYXRlIEF1dGhvcml0aWVzMSUwIwYD
VQQDExxXZWxscyBGYXJnbyBFbnRlcnByaXNlIENBIDAyMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAm1mEVgXlHHbd4DrKFIROTf6Q5JwzJEtjFiWN4lQs
EvKeVN1p7/ua16c0gFhizQvuD002pttUG7Tn6uUonUYxJajD2TnykAQu1m5Ks1gi
sNgYCGzH8tluKeWYANppSRt5F1Is3YtsNOGiYtVFnZf3FejOzVWkhnT5rYXjTf9O
su5KK1Jh7NywbFU5P2ytC4h/M9xnlHuCjy7RBmN956iG7Eb+BBrvo7ZfTfzWuFzm
vficKovoDbZOloLHHsRzj2iQ2euY+xW/g+Zn1lHPQCZfTdLgPUcnV7qpP+1fRVy5
hNLQTw3nBrNa5RLIZK8RBpY6kig4wWhyNKP+9Ssc2m34lQIDAQABo4ICMTCCAi0w
DwYDVR0TAQH/BAUwAwEB/zCBgwYDVR0gBHwwejA7BgtghkgBhvt7g3QAADAsMCoG
CCsGAQUFBwIBFh5odHRwOi8vd3d3LndlbGxzZmFyZ28uY29tL2Nwcy8wOwYLYIZI
AYb7e4N0AAEwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy53ZWxsc2ZhcmdvLmNv
bS9jcHMvMHcGCCsGAQUFBwEBBGswaTAwBggrBgEFBQcwAYYkaHR0cDovL29jc3At
cm9vdC5wa2kud2VsbHNmYXJnby5jb20vMDUGCCsGAQUFBzAChilodHRwOi8vY3Js
LnBraS53ZWxsc2ZhcmdvLmNvbS93Zl9yb290LmNydDAOBgNVHQ8BAf8EBAMCAfYw
gbIGA1UdIwSBqjCBp4AUFK8Y973m52vjWvrqUe/+1FpxOcChgYikgYUwgYIxCzAJ
BgNVBAYTAlVTMRQwEgYDVQQKEwtXZWxscyBGYXJnbzEsMCoGA1UECxMjV2VsbHMg
RmFyZ28gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxLzAtBgNVBAMTJldlbGxzIEZh
cmdvIFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5ggQ55JeeMDcGA1UdHwQwMC4w
LKAqoCiGJmh0dHA6Ly9jcmwucGtpLndlbGxzZmFyZ28uY29tL3Jvb3QuY3JsMB0G
A1UdDgQWBBTEq0W2OgsBHGJcyj/H480vMMRX1zANBgkqhkiG9w0BAQUFAAOCAQEA
LUIw6yFNj7mrTSIuqtT6rsAXgKApylI3HtepbWa6qxEmmDDjCAaOxXZKShTxBQa6
qSpYFg0KFxqKsNiot8CAEMxXcapr5OLwytTFvnDSRa9H+mlLT6jpZi8C3fbqEvbV
eh7NjT4oj8fNbsf13UgN0xxlgiez47locWVADdYP/RucG31o+8OqJaZ/+AWsc+B6
LoQ9jaYlYaiXXERQopLS8dxTeGp8pvmdYK4ghHG/AwLW0fEcaqQOqrBcf8A+3/RQ
YEdJ62vZ8Q9T6HwbdPr0zToqeVM5i+DgLjy2fq1eEp6a5In0N78tkgEr8NPlpPgb
93C6T8kNYioQY20dNklqLQ==
-----END CERTIFICATE-----

subject= /C=US/O=Wells Fargo/OU=Wells Fargo Certification Authority/CN=Wells
Fargo Root Certificate Authority issuer= /C=US/O=Wells Fargo/OU=Wells Fargo
Certification Authority/CN=Wells Fargo Root Certificate Authority
notBefore=Oct 11 16:41:28 2000 GMT notAfter=Jan 14 16:41:28 2021 GMT
SHA1 Fingerprint=93:E6:AB:22:03:03:B5:23:28:DC:DA:56:9E:BA:E4:D1:D1:CC:FB:65
-----BEGIN CERTIFICATE-----
MIID5TCCAs2gAwIBAgIEOeSXnjANBgkqhkiG9w0BAQUFADCBgjELMAkGA1UEBhMC
VVMxFDASBgNVBAoTC1dlbGxzIEZhcmdvMSwwKgYDVQQLEyNXZWxscyBGYXJnbyBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEvMC0GA1UEAxMmV2VsbHMgRmFyZ28gUm9v
dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDAxMDExMTY0MTI4WhcNMjEwMTE0
MTY0MTI4WjCBgjELMAkGA1UEBhMCVVMxFDASBgNVBAoTC1dlbGxzIEZhcmdvMSww
KgYDVQQLEyNXZWxscyBGYXJnbyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEvMC0G
A1UEAxMmV2VsbHMgRmFyZ28gUm9vdCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDVqDM7Jvk0/82bfuUER84A4n13
5zHCLielTWi5MbqNQ1mXx3Oqfz1cQJ4F5aHiidlMuD+b+Qy0yGIZLEWukR5zcUHE
SxP9cMIlrCL1dQu3U+SlK93OvRw6esP3E48mVJwWa2uv+9iWsWCaSOAlIiR5NM4O
JgALTqv9i86C1y8IcGjBqAr5dE8Hq6T54oN+J3N0Prj5OEL8pahbSCOz6+MlsoCu
ltQKnMJ4msZoGK43YjdeUXWoWGPAUe5AeH6orxqg4bB4nVCMe+ez/I4jsNtlAHCE
AQgAFG5Uhpq6zPk3EPbg3oQtnaSFN9OH4xXQwReQfhkhahKpdv0SAulPIV4XAgMB
AAGjYTBfMA8GA1UdEwEB/wQFMAMBAf8wTAYDVR0gBEUwQzBBBgtghkgBhvt7hwcB
CzAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3LndlbGxzZmFyZ28uY29tL2NlcnRw
b2xpY3kwDQYJKoZIhvcNAQEFBQADggEBANIn3ZwKdyu7IvICtUpKkfnRLb7kuxpo
7w6kAOnu5+/u9vnldKTC2FJYxHT7zmu1Oyl5GFrvm+0fazbuSCUlFLZWohDo7qd/
0D+j0MNdJu4HzMPBJCGHHt8qElNvQRbn7a6U+oxy+hNH8Dx+rn0ROhPs7fpvcmR7
nX1/Jv16+yWt6j4pf0zjAFcysLPp7VMX2YuyFA4w6OXVE8Zkr8QA1dhYJPz1j+zx
x32l2w8n0cbyQIjmH/ZhqPRCyLk306m+LFZ4wnKbWV01QIroTmMatukgalHizqSQ
33ZwmVxwQ023tqcZZE6St8WRPH9IFmV7Fv3L/PvZ1dZPIWU7Sn9Ho/s=
-----END CERTIFICATE-----
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Viktor Dukhovni]

Post by Liz Fall
// only really need a PEM on the server side
mongo::sslGlobalParams.sslPEMKeyFile = "<path/to/keyfile.pem>";

The comment is highly misleading. PEM is a "meta" format. It
encapsulates base64 encoded blobs between BEGIN/END headers/trailers,
allowing multiple objects to be concatenated unambiguously and
transported undamaged via ASCII email.

This this is a client, what goes here is likely a client certificate
chain and a client private key, or just NULL, if client certificates
are not employed (you're likely authenticating the client with a
username and password instead).

------ BEGIN RSA PRIVATE KEY -----
private key for client cert base64 encoded
------ END RSA PRIVATE KEY -----
client cert base64 encoded
------ END CERTIFICATE -----
------ BEGIN CERTIFICATE -----
intermediate issuer base64 encoded
------ END CERTIFICATE -----
...
------ BEGIN CERTIFICATE -----
root issuer base64 encoded
------ END CERTIFICATE -----

I would try NULL first. You may need to separately specify a
CAfile, or CApath for validating the server certificate.

[Liz Fall]

Hi Viktor,

Thanks for the info. I will try what you suggested today. However, I am a
bit confused by what you are saying - You may need to separately specify a
CAfile, or CApath for validating the server certificate. I have the two pem
files below. I thought the
DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_server.pem file resided on the
MongoDB database server and I was supposed to connect from my C++ app with
the DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem file. I am new to
this, so I am sorry for not understanding completely.

. DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_server.pem
. private key of DTCD9C3B2F42757.ent.wfb.bank.corp machine
. certificate for DTCD9C3B2F42757.ent.wfb.bank.corp, signed by WF
Enterprise CA 02

. DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem
. WF Enterprise CA 02 certificate, signed by WF Root
. WF Root certificate

Thanks,
Liz

-----Original Message-----
From: owner-openssl-users-MCmKBN63+***@public.gmane.org
[mailto:owner-openssl-users-MCmKBN63+***@public.gmane.org] On Behalf Of Viktor Dukhovni
Sent: Monday, September 08, 2014 8:28 PM
To: openssl-users-MCmKBN63+***@public.gmane.org
Subject: Re: cannot read PEM key file - no start line

Post by Liz Fall
// only really need a PEM on the server side
mongo::sslGlobalParams.sslPEMKeyFile = "<path/to/keyfile.pem>";

The comment is highly misleading. PEM is a "meta" format. It encapsulates
base64 encoded blobs between BEGIN/END headers/trailers, allowing multiple
objects to be concatenated unambiguously and transported undamaged via ASCII
email.

This this is a client, what goes here is likely a client certificate chain
and a client private key, or just NULL, if client certificates are not
employed (you're likely authenticating the client with a username and
password instead).

------ BEGIN RSA PRIVATE KEY -----
private key for client cert base64 encoded
------ END RSA PRIVATE KEY -----
client cert base64 encoded
------ END CERTIFICATE -----
------ BEGIN CERTIFICATE -----
intermediate issuer base64 encoded
------ END CERTIFICATE -----
...
------ BEGIN CERTIFICATE -----
root issuer base64 encoded
------ END CERTIFICATE -----

I would try NULL first. You may need to separately specify a CAfile, or
CApath for validating the server certificate.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Viktor Dukhovni]

Post by Liz Fall
Thanks for the info. I will try what you suggested today. However, I am a
bit confused by what you are saying - You may need to separately specify a
CAfile, or CApath for validating the server certificate. I have the two pem
files below.

Most applications that use TLS do not employ client certificates.

In such applications the server typically has a certificate chain
file (containing its certificate and those of issuing CAs ordered
from leaf to optional root) and a private key file (which may be
the same as the chain file, since PEM can store multiple objects
of various types in a single file).

The client typically has no certificate chain file or private key,
rather it needs to be able to verify the server certificate. Thus
it needs to specify the location (or employ the system default) of
the file or directory holding trusted issuer certificates.

Post by Liz Fall
I thought the
DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_server.pem file resided on the
MongoDB database server and I was supposed to connect from my C++ app with
the DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem file.

Or perhaps you're supposed to simply append the intermediate CA
certs in the second to the leaf server certificate in the first,
and employ the result (with a suitable private key) on the server
side.

Only the client side, you'll need just the root CA cert in the
default system location (see docs for c_rehash) or explicitly
loaded by the client as a "CAfile".

[Michael Sierchio]

2014-09-03T13:37:56.881-0500 ERROR: cannot read PEM key file: /users/apps/tstlrn/u019807/DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem error:0906D06C:PEM routines:PEM_read_bio:no start line

Cert file or key file? The error indicates that the client can't find
the private key.

free from viruses and malware because avast! Antivirus protection is active.

Thanks for that amusing bit of insight.

- M
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Jeffrey Walton]

Post by Liz Fall
All,
I am getting the following with my client cert when trying to connect to
/users/apps/tstlrn/u019807/DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem
error:0906D06C:PEM routines:PEM_read_bio:no start line

I just tried to duplicate with a key (not a certificate) that uses line
breaks at 76 characters. I don't have a certificate because my routines
don't support certificates. But it should reveal a little about the OpenSSL
parser.

Reading the public and private keys were OK when the line size was 76 (see
below). So the OpenSSL parser is lenient during a read. This seems very
reasonable to me.

Reading an encrypted private key resulted in an error "PEM_read_bio:bad end
line:pem_lib.c:802" when the line size was 76 (see below). This kind of
surprised me.

Since you are receiving the "no start line" error (and not another error),
I would suspect you are reading an ASN.1/DER encoded certificate; and not a
PEM encoded certificate. The error occured before anything related to line
lengths.

Can you post the X509 certificate for inspection?

Jeff

**********

# Line breaks at 76
$ cat rsa-pub-xxx.pem
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDse17vxd2lkVIxwt1gkipo0EZo3NdDhIvPRowZ
6hfRM1n3+8NlS4Qw76PvM1EMR9FXCFTBtv9zzZ7OkNH84LgG6mbNS28PuWeUFmMZumdLbT4KNu2U
pttFup08OUEIlrmkeP1GqMCfaVcbCfl0tScpCMeEhXUpiIvtzUin2kqGHQIDAQAB
-----END PUBLIC KEY-----

# Line breaks at 76
$ cat rsa-priv-xxx.pem
-----BEGIN RSA PRIVATE KEY-----
MIICXgIBAAKBgQDse17vxd2lkVIxwt1gkipo0EZo3NdDhIvPRowZ6hfRM1n3+8NlS4Qw76PvM1EM
R9FXCFTBtv9zzZ7OkNH84LgG6mbNS28PuWeUFmMZumdLbT4KNu2UpttFup08OUEIlrmkeP1GqMCf
aVcbCfl0tScpCMeEhXUpiIvtzUin2kqGHQIDAQABAoGBAJqxzZW98tMW8BS7K0O7+eActqJsLKjv
MOIDfSyKlM/17pmo6NX/g1bbvHqCMDd/V3K+cWtTAWJIlOT9mU/51Ib3h29xEQQ6Ql/ubMPAmm/t
f7itQMxn5FVY+ZA2/pL/mDzAdMuLeS/1TcHCqjbpAL8VaZjHTqztHBcVcNzbIQ6BAkEA/e7hE6WV
caAoFEVfoZW0AIjwWpziQdI1bhNAi70fxWEU1kSq2ZZZhqxU4G37IKmVfBnx3CSzCgp5daPqUpEO
oQJBAO5oIOgVf3GqL03fA6N3s2gx9L4VzAaZZynDF6yjhCCAXs8uUSEYKL32a17dFq+0SrQUSS2J
Tylsz2cv+Uk6cf0CQQCV5RLb5BypbB78iE8BNTuCLVOkSYON0yZTCe5KDqPYgYwpR3OK6aODSer4
aDObfj+NeEs65jcBsFkuRkol3xbBAkEAiN+rlNNS2fU1N2YEdsNwcy/LLZ7iBh/ohKeHXgx6/RX2
WMhkt7VhHr7tIgeY0MOX6A+Fe+lLU6Mu6DU4z/wIGQJAQfEGaJbtaq8bLu6m2VYPpGig1NyBx9i8
kF/E+JC9ZSYh//5nhp6+lBbxceDcijPqnKGZlMYS51nPLSHQBRqbog==
-----END RSA PRIVATE KEY-----

# Line breaks at 76, password is "test"
$ cat rsa-enc-priv-xxx.pem
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,8878824B00BA92932DC5AA1E4A9F12E0

klcOjPvZmj/19sUcf031oUckm2YUw7nEp6UtSbs41OKd2TyRfveNl4vv3J8AzOh18AqPPSKR3chM
8lSvKIdcksieh8raqr2s5wMd8ds/mDkguoVWGVnN8f+FKoVTny7OMhXAbQhk2ZXwZMEU5Q8M/Jnj
3ZfrbgcLYH50UoPlkgD6Y0krcNB+TDJEMvErn7G6RedrDPOjQ2gFCmRSE6Yuqtcgl5JaVS+1UT8Z
4l+EMuUjQcBiwuSQNxgfwyGQ3g/2maluLJsEKHDQhAKufe2c7lXlK/0MdHY+q4RbNLmGBigHb97U
A5jTZl5+dBrQgtgPx7V13F/7EHT6m2KrYSDvfoPadcT65sT1ukoZF5rvbdRcN1QtVetVrymwM5XU
8CrlSz6tihleipPx27JUA7WQjIQc/Kk7R0e1dNB0oEkgd0i5+20bg+4/Keh0t5fwkXlyrCwjEItT
zoC0Hm2dvXG6BTm1OUyRL94DxStVmqRpwDbthbEUqxYWrxTgWKu+noGYu3xJFI6plKEHTY+YMxjm
azeyV8CE0HGwRXTBHpj47bekt5dpxMxZasgeIJqHrUI3am+CijdJTHQyHU3Zxk7rdiLha1inpN6M
Z+ImQxqzm22e4/KMnTxcZ7L6hNzCKXgAGZ9gdg2uV+fwwyFRwzLDWMbQFeYH10yHB6Ua6Wg2LZdr
+NTuJlrMykVULD382XszNMLFtJGl46lpJ9XKWTTIX4e5Fg5N1WSHS2gD8YLxtRzd9vM9ewsZOMtw
gqw5uK7GSJUo8FHKtYuLGKY0jnVHFm2VnYo+76RXQxmJyo+ANmALJCJENCZDMm0I0pRGgRVV
-----END RSA PRIVATE KEY-----

$ openssl rsa -in rsa-pub-xxx.pem -pubin -text -noout
Public-Key: (1024 bit)
Modulus:
00:ec:7b:5e:ef:c5:dd:a5:91:52:31:c2:dd:60:92:
2a:68:d0:46:68:dc:d7:43:84:8b:cf:46:8c:19:ea:
17:d1:33:59:f7:fb:c3:65:4b:84:30:ef:a3:ef:33:
51:0c:47:d1:57:08:54:c1:b6:ff:73:cd:9e:ce:90:
d1:fc:e0:b8:06:ea:66:cd:4b:6f:0f:b9:67:94:16:
63:19:ba:67:4b:6d:3e:0a:36:ed:94:a6:db:45:ba:
9d:3c:39:41:08:96:b9:a4:78:fd:46:a8:c0:9f:69:
57:1b:09:f9:74:b5:27:29:08:c7:84:85:75:29:88:
8b:ed:cd:48:a7:da:4a:86:1d
Exponent: 65537 (0x10001)

$ openssl rsa -in rsa-priv-xxx.pem -text -noout
Private-Key: (1024 bit)
modulus:
00:ec:7b:5e:ef:c5:dd:a5:91:52:31:c2:dd:60:92:
2a:68:d0:46:68:dc:d7:43:84:8b:cf:46:8c:19:ea:
17:d1:33:59:f7:fb:c3:65:4b:84:30:ef:a3:ef:33:
51:0c:47:d1:57:08:54:c1:b6:ff:73:cd:9e:ce:90:
d1:fc:e0:b8:06:ea:66:cd:4b:6f:0f:b9:67:94:16:
63:19:ba:67:4b:6d:3e:0a:36:ed:94:a6:db:45:ba:
9d:3c:39:41:08:96:b9:a4:78:fd:46:a8:c0:9f:69:
57:1b:09:f9:74:b5:27:29:08:c7:84:85:75:29:88:
8b:ed:cd:48:a7:da:4a:86:1d
publicExponent: 65537 (0x10001)
privateExponent:
00:9a:b1:cd:95:bd:f2:d3:16:f0:14:bb:2b:43:bb:
f9:e0:1c:b6:a2:6c:2c:a8:ef:30:e2:03:7d:2c:8a:
94:cf:f5:ee:99:a8:e8:d5:ff:83:56:db:bc:7a:82:
30:37:7f:57:72:be:71:6b:53:01:62:48:94:e4:fd:
99:4f:f9:d4:86:f7:87:6f:71:11:04:3a:42:5f:ee:
6c:c3:c0:9a:6f:ed:7f:b8:ad:40:cc:67:e4:55:58:
f9:90:36:fe:92:ff:98:3c:c0:74:cb:8b:79:2f:f5:
4d:c1:c2:aa:36:e9:00:bf:15:69:98:c7:4e:ac:ed:
1c:17:15:70:dc:db:21:0e:81
prime1:
00:fd:ee:e1:13:a5:95:71:a0:28:14:45:5f:a1:95:
b4:00:88:f0:5a:9c:e2:41:d2:35:6e:13:40:8b:bd:
1f:c5:61:14:d6:44:aa:d9:96:59:86:ac:54:e0:6d:
fb:20:a9:95:7c:19:f1:dc:24:b3:0a:0a:79:75:a3:
ea:52:91:0e:a1
prime2:
00:ee:68:20:e8:15:7f:71:aa:2f:4d:df:03:a3:77:
b3:68:31:f4:be:15:cc:06:99:67:29:c3:17:ac:a3:
84:20:80:5e:cf:2e:51:21:18:28:bd:f6:6b:5e:dd:
16:af:b4:4a:b4:14:49:2d:89:4f:29:6c:cf:67:2f:
f9:49:3a:71:fd
exponent1:
00:95:e5:12:db:e4:1c:a9:6c:1e:fc:88:4f:01:35:
3b:82:2d:53:a4:49:83:8d:d3:26:53:09:ee:4a:0e:
a3:d8:81:8c:29:47:73:8a:e9:a3:83:49:ea:f8:68:
33:9b:7e:3f:8d:78:4b:3a:e6:37:01:b0:59:2e:46:
4a:25:df:16:c1
exponent2:
00:88:df:ab:94:d3:52:d9:f5:35:37:66:04:76:c3:
70:73:2f:cb:2d:9e:e2:06:1f:e8:84:a7:87:5e:0c:
7a:fd:15:f6:58:c8:64:b7:b5:61:1e:be:ed:22:07:
98:d0:c3:97:e8:0f:85:7b:e9:4b:53:a3:2e:e8:35:
38:cf:fc:08:19
coefficient:
41:f1:06:68:96:ed:6a:af:1b:2e:ee:a6:d9:56:0f:
a4:68:a0:d4:dc:81:c7:d8:bc:90:5f:c4:f8:90:bd:
65:26:21:ff:fe:67:86:9e:be:94:16:f1:71:e0:dc:
8a:33:ea:9c:a1:99:94:c6:12:e7:59:cf:2d:21:d0:
05:1a:9b:a2

$ openssl rsa -in rsa-enc-priv-xxx.pem -passin pass:test -text -noout
unable to load Private Key
140735192314332:error:0906D066:PEM routines:PEM_read_bio:bad end
line:pem_lib.c:802:

[Liz Fall]

Hi Jeff,



Please find the certificates attached.



openssl x509 -in DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pembackup -inform PEM -text -noout

Certificate:

Data:

Version: 3 (0x2)

Serial Number: 1085434364 (0x40b269fc)

Signature Algorithm: sha1WithRSAEncryption

Issuer: C=US, O=Wells Fargo, OU=Wells Fargo Certification Authority, CN=Wells Fargo Root Certificate Authority

Validity

Not Before: May 28 18:17:26 2009 GMT

Not After : May 28 18:17:26 2019 GMT

Subject: C=US, O=Wells Fargo, OU=Wells Fargo Certificate Authorities, CN=Wells Fargo Enterprise CA 02

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (2048 bit)

Modulus:

00:9b:59:84:56:05:e5:1c:76:dd:e0:3a:ca:14:84:

4e:4d:fe:90:e4:9c:33:24:4b:63:16:25:8d:e2:54:

2c:12:f2:9e:54:dd:69:ef:fb:9a:d7:a7:34:80:58:

62:cd:0b:ee:0f:4d:36:a6:db:54:1b:b4:e7:ea:e5:

28:9d:46:31:25:a8:c3:d9:39:f2:90:04:2e:d6:6e:

4a:b3:58:22:b0:d8:18:08:6c:c7:f2:d9:6e:29:e5:

98:00:da:69:49:1b:79:17:52:2c:dd:8b:6c:34:e1:

a2:62:d5:45:9d:97:f7:15:e8:ce:cd:55:a4:86:74:

f9:ad:85:e3:4d:ff:4e:b2:ee:4a:2b:52:61:ec:dc:

b0:6c:55:39:3f:6c:ad:0b:88:7f:33:dc:67:94:7b:

82:8f:2e:d1:06:63:7d:e7:a8:86:ec:46:fe:04:1a:

ef:a3:b6:5f:4d:fc:d6:b8:5c:e6:bd:f8:9c:2a:8b:

e8:0d:b6:4e:96:82:c7:1e:c4:73:8f:68:90:d9:eb:

98:fb:15:bf:83:e6:67:d6:51:cf:40:26:5f:4d:d2:

e0:3d:47:27:57:ba:a9:3f:ed:5f:45:5c:b9:84:d2:

d0:4f:0d:e7:06:b3:5a:e5:12:c8:64:af:11:06:96:

3a:92:28:38:c1:68:72:34:a3:fe:f5:2b:1c:da:6d:

f8:95

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Basic Constraints: critical

CA:TRUE

X509v3 Certificate Policies:

Policy: 2.16.840.1.114171.500.0.0

CPS: http://www.wellsfargo.com/cps/

Policy: 2.16.840.1.114171.500.0.1

CPS: http://www.wellsfargo.com/cps/



Authority Information Access:

OCSP - URI:http://ocsp-root.pki.wellsfargo.com/

CA Issuers - URI:http://crl.pki.wellsfargo.com/wf_root.crt



X509v3 Key Usage: critical

Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, Certificate Sign, CRL Sign

X509v3 Authority Key Identifier:

keyid:14:AF:18:F7:BD:E6:E7:6B:E3:5A:FA:EA:51:EF:FE:D4:5A:71:39:C0

DirName:/C=US/O=Wells Fargo/OU=Wells Fargo Certification Authority/CN=Wells Fargo Root Certificate Authority

serial:39:E4:97:9E



X509v3 CRL Distribution Points:



Full Name:

URI:http://crl.pki.wellsfargo.com/root.crl



X509v3 Subject Key Identifier:

C4:AB:45:B6:3A:0B:01:1C:62:5C:CA:3F:C7:E3:CD:2F:30:C4:57:D7

Signature Algorithm: sha1WithRSAEncryption

2d:42:30:eb:21:4d:8f:b9:ab:4d:22:2e:aa:d4:fa:ae:c0:17:

80:a0:29:ca:52:37:1e:d7:a9:6d:66:ba:ab:11:26:98:30:e3:

08:06:8e:c5:76:4a:4a:14:f1:05:06:ba:a9:2a:58:16:0d:0a:

17:1a:8a:b0:d8:a8:b7:c0:80:10:cc:57:71:aa:6b:e4:e2:f0:

ca:d4:c5:be:70:d2:45:af:47:fa:69:4b:4f:a8:e9:66:2f:02:

dd:f6:ea:12:f6:d5:7a:1e:cd:8d:3e:28:8f:c7:cd:6e:c7:f5:

dd:48:0d:d3:1c:65:82:27:b3:e3:b9:68:71:65:40:0d:d6:0f:

fd:1b:9c:1b:7d:68:fb:c3:aa:25:a6:7f:f8:05:ac:73:e0:7a:

2e:84:3d:8d:a6:25:61:a8:97:5c:44:50:a2:92:d2:f1:dc:53:

78:6a:7c:a6:f9:9d:60:ae:20:84:71:bf:03:02:d6:d1:f1:1c:

6a:a4:0e:aa:b0:5c:7f:c0:3e:df:f4:50:60:47:49:eb:6b:d9:

f1:0f:53:e8:7c:1b:74:fa:f4:cd:3a:2a:79:53:39:8b:e0:e0:

2e:3c:b6:7e:ad:5e:12:9e:9a:e4:89:f4:37:bf:2d:92:01:2b:

f0:d3:e5:a4:f8:1b:f7:70:ba:4f:c9:0d:62:2a:10:63:6d:1d:

36:49:6a:2d



This is the C++ MongoDB API I am using to connect to the database:



#include "mongo/util/net/ssl_options.h"

#include "mongo/client/init.h"



int main() {

sslGlobalParams.sslMode.store(SSLGlobalParams::SSLMode_requireSSL);



// only really need a PEM on the server side

mongo::sslGlobalParams.sslPEMKeyFile = "<path/to/keyfile.pem>";



mongo::Status status = mongo::client::initialize();



if (!status.isOK())

::abort();



DBClientConnection c;

c.connect("hostname.whatever.com"); // outgoing connections are SSL

}



My question to MongoDB support was: From the code above, the comment states that there is only a need of a PEM on the server side. What identifies the "key store" on the C++ client server? Is as key store not required on the

C++ linux server where my application is running?



MongoDB support response was: That is correct. For encrypted communications only the MongoDB server needs a PEM file.



I am just not sure what I am supposed to be providing as far as the sslPEMKeyFile. I have these certificates:



For MongoDB files are in PEM format:

· DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_server.pem

· private key of DTCD9C3B2F42757.ent.wfb.bank.corp machine

· certificate for DTCD9C3B2F42757.ent.wfb.bank.corp, signed by WF Enterprise CA 02

· DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem

· WF Enterprise CA 02 certificate, signed by WF Root

· WF Root certificate

I get these errors trying when trying to use each cert separately:

· 2014-09-03T13:46:42.186-0500 ERROR: cannot read PEM key file: /users/apps/tstlrn/u019807/DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_server.pem error:0906406D:PEM routines:PEM_def_callback:problems getting password



· 2014-09-03T13:37:56.881-0500 ERROR: cannot read PEM key file: /users/apps/tstlrn/u019807/DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem error:0906D06C:PEM routines:PEM_read_bio:no start line





Please me know if you need any additional information.



Thanks for your help,

Liz

From: owner-openssl-users-MCmKBN63+***@public.gmane.org [mailto:owner-openssl-***@openssl.org] On Behalf Of Jeffrey Walton
Sent: Tuesday, September 09, 2014 5:09 AM
To: OpenSSL Users List
Subject: Re: cannot read PEM key file - no start line







On Sun, Sep 7, 2014 at 10:26 PM, Liz Fall <fall-***@public.gmane.org> wrote:

All,



I am getting the following with my client cert when trying to connect to an SSL-enabled MongoDB:



2014-09-03T13:37:56.881-0500 ERROR: cannot read PEM key file: /users/apps/tstlrn/u019807/DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem error:0906D06C:PEM routines:PEM_read_bio:no start line

I just tried to duplicate with a key (not a certificate) that uses line breaks at 76 characters. I don't have a certificate because my routines don't support certificates. But it should reveal a little about the OpenSSL parser.

Reading the public and private keys were OK when the line size was 76 (see below). So the OpenSSL parser is lenient during a read. This seems very reasonable to me.

Reading an encrypted private key resulted in an error "PEM_read_bio:bad end line:pem_lib.c:802" when the line size was 76 (see below). This kind of surprised me.

Since you are receiving the "no start line" error (and not another error), I would suspect you are reading an ASN.1/DER encoded certificate; and not a PEM encoded certificate. The error occured before anything related to line lengths.

Can you post the X509 certificate for inspection?

Jeff

**********



# Line breaks at 76

$ cat rsa-pub-xxx.pem
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDse17vxd2lkVIxwt1gkipo0EZo3NdDhIvPRowZ
6hfRM1n3+8NlS4Qw76PvM1EMR9FXCFTBtv9zzZ7OkNH84LgG6mbNS28PuWeUFmMZumdLbT4KNu2U
pttFup08OUEIlrmkeP1GqMCfaVcbCfl0tScpCMeEhXUpiIvtzUin2kqGHQIDAQAB
-----END PUBLIC KEY-----

# Line breaks at 76
$ cat rsa-priv-xxx.pem
-----BEGIN RSA PRIVATE KEY-----
MIICXgIBAAKBgQDse17vxd2lkVIxwt1gkipo0EZo3NdDhIvPRowZ6hfRM1n3+8NlS4Qw76PvM1EM
R9FXCFTBtv9zzZ7OkNH84LgG6mbNS28PuWeUFmMZumdLbT4KNu2UpttFup08OUEIlrmkeP1GqMCf
aVcbCfl0tScpCMeEhXUpiIvtzUin2kqGHQIDAQABAoGBAJqxzZW98tMW8BS7K0O7+eActqJsLKjv
MOIDfSyKlM/17pmo6NX/g1bbvHqCMDd/V3K+cWtTAWJIlOT9mU/51Ib3h29xEQQ6Ql/ubMPAmm/t
f7itQMxn5FVY+ZA2/pL/mDzAdMuLeS/1TcHCqjbpAL8VaZjHTqztHBcVcNzbIQ6BAkEA/e7hE6WV
caAoFEVfoZW0AIjwWpziQdI1bhNAi70fxWEU1kSq2ZZZhqxU4G37IKmVfBnx3CSzCgp5daPqUpEO
oQJBAO5oIOgVf3GqL03fA6N3s2gx9L4VzAaZZynDF6yjhCCAXs8uUSEYKL32a17dFq+0SrQUSS2J
Tylsz2cv+Uk6cf0CQQCV5RLb5BypbB78iE8BNTuCLVOkSYON0yZTCe5KDqPYgYwpR3OK6aODSer4
aDObfj+NeEs65jcBsFkuRkol3xbBAkEAiN+rlNNS2fU1N2YEdsNwcy/LLZ7iBh/ohKeHXgx6/RX2
WMhkt7VhHr7tIgeY0MOX6A+Fe+lLU6Mu6DU4z/wIGQJAQfEGaJbtaq8bLu6m2VYPpGig1NyBx9i8
kF/E+JC9ZSYh//5nhp6+lBbxceDcijPqnKGZlMYS51nPLSHQBRqbog==
-----END RSA PRIVATE KEY-----

# Line breaks at 76, password is "test"
$ cat rsa-enc-priv-xxx.pem
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,8878824B00BA92932DC5AA1E4A9F12E0

klcOjPvZmj/19sUcf031oUckm2YUw7nEp6UtSbs41OKd2TyRfveNl4vv3J8AzOh18AqPPSKR3chM
8lSvKIdcksieh8raqr2s5wMd8ds/mDkguoVWGVnN8f+FKoVTny7OMhXAbQhk2ZXwZMEU5Q8M/Jnj
3ZfrbgcLYH50UoPlkgD6Y0krcNB+TDJEMvErn7G6RedrDPOjQ2gFCmRSE6Yuqtcgl5JaVS+1UT8Z
4l+EMuUjQcBiwuSQNxgfwyGQ3g/2maluLJsEKHDQhAKufe2c7lXlK/0MdHY+q4RbNLmGBigHb97U
A5jTZl5+dBrQgtgPx7V13F/7EHT6m2KrYSDvfoPadcT65sT1ukoZF5rvbdRcN1QtVetVrymwM5XU
8CrlSz6tihleipPx27JUA7WQjIQc/Kk7R0e1dNB0oEkgd0i5+20bg+4/Keh0t5fwkXlyrCwjEItT
zoC0Hm2dvXG6BTm1OUyRL94DxStVmqRpwDbthbEUqxYWrxTgWKu+noGYu3xJFI6plKEHTY+YMxjm
azeyV8CE0HGwRXTBHpj47bekt5dpxMxZasgeIJqHrUI3am+CijdJTHQyHU3Zxk7rdiLha1inpN6M
Z+ImQxqzm22e4/KMnTxcZ7L6hNzCKXgAGZ9gdg2uV+fwwyFRwzLDWMbQFeYH10yHB6Ua6Wg2LZdr
+NTuJlrMykVULD382XszNMLFtJGl46lpJ9XKWTTIX4e5Fg5N1WSHS2gD8YLxtRzd9vM9ewsZOMtw
gqw5uK7GSJUo8FHKtYuLGKY0jnVHFm2VnYo+76RXQxmJyo+ANmALJCJENCZDMm0I0pRGgRVV
-----END RSA PRIVATE KEY-----

$ openssl rsa -in rsa-pub-xxx.pem -pubin -text -noout
Public-Key: (1024 bit)
Modulus:
00:ec:7b:5e:ef:c5:dd:a5:91:52:31:c2:dd:60:92:
2a:68:d0:46:68:dc:d7:43:84:8b:cf:46:8c:19:ea:
17:d1:33:59:f7:fb:c3:65:4b:84:30:ef:a3:ef:33:
51:0c:47:d1:57:08:54:c1:b6:ff:73:cd:9e:ce:90:
d1:fc:e0:b8:06:ea:66:cd:4b:6f:0f:b9:67:94:16:
63:19:ba:67:4b:6d:3e:0a:36:ed:94:a6:db:45:ba:
9d:3c:39:41:08:96:b9:a4:78:fd:46:a8:c0:9f:69:
57:1b:09:f9:74:b5:27:29:08:c7:84:85:75:29:88:
8b:ed:cd:48:a7:da:4a:86:1d
Exponent: 65537 (0x10001)

$ openssl rsa -in rsa-priv-xxx.pem -text -noout
Private-Key: (1024 bit)
modulus:
00:ec:7b:5e:ef:c5:dd:a5:91:52:31:c2:dd:60:92:
2a:68:d0:46:68:dc:d7:43:84:8b:cf:46:8c:19:ea:
17:d1:33:59:f7:fb:c3:65:4b:84:30:ef:a3:ef:33:
51:0c:47:d1:57:08:54:c1:b6:ff:73:cd:9e:ce:90:
d1:fc:e0:b8:06:ea:66:cd:4b:6f:0f:b9:67:94:16:
63:19:ba:67:4b:6d:3e:0a:36:ed:94:a6:db:45:ba:
9d:3c:39:41:08:96:b9:a4:78:fd:46:a8:c0:9f:69:
57:1b:09:f9:74:b5:27:29:08:c7:84:85:75:29:88:
8b:ed:cd:48:a7:da:4a:86:1d
publicExponent: 65537 (0x10001)
privateExponent:
00:9a:b1:cd:95:bd:f2:d3:16:f0:14:bb:2b:43:bb:
f9:e0:1c:b6:a2:6c:2c:a8:ef:30:e2:03:7d:2c:8a:
94:cf:f5:ee:99:a8:e8:d5:ff:83:56:db:bc:7a:82:
30:37:7f:57:72:be:71:6b:53:01:62:48:94:e4:fd:
99:4f:f9:d4:86:f7:87:6f:71:11:04:3a:42:5f:ee:
6c:c3:c0:9a:6f:ed:7f:b8:ad:40:cc:67:e4:55:58:
f9:90:36:fe:92:ff:98:3c:c0:74:cb:8b:79:2f:f5:
4d:c1:c2:aa:36:e9:00:bf:15:69:98:c7:4e:ac:ed:
1c:17:15:70:dc:db:21:0e:81
prime1:
00:fd:ee:e1:13:a5:95:71:a0:28:14:45:5f:a1:95:
b4:00:88:f0:5a:9c:e2:41:d2:35:6e:13:40:8b:bd:
1f:c5:61:14:d6:44:aa:d9:96:59:86:ac:54:e0:6d:
fb:20:a9:95:7c:19:f1:dc:24:b3:0a:0a:79:75:a3:
ea:52:91:0e:a1
prime2:
00:ee:68:20:e8:15:7f:71:aa:2f:4d:df:03:a3:77:
b3:68:31:f4:be:15:cc:06:99:67:29:c3:17:ac:a3:
84:20:80:5e:cf:2e:51:21:18:28:bd:f6:6b:5e:dd:
16:af:b4:4a:b4:14:49:2d:89:4f:29:6c:cf:67:2f:
f9:49:3a:71:fd
exponent1:
00:95:e5:12:db:e4:1c:a9:6c:1e:fc:88:4f:01:35:
3b:82:2d:53:a4:49:83:8d:d3:26:53:09:ee:4a:0e:
a3:d8:81:8c:29:47:73:8a:e9:a3:83:49:ea:f8:68:
33:9b:7e:3f:8d:78:4b:3a:e6:37:01:b0:59:2e:46:
4a:25:df:16:c1
exponent2:
00:88:df:ab:94:d3:52:d9:f5:35:37:66:04:76:c3:
70:73:2f:cb:2d:9e:e2:06:1f:e8:84:a7:87:5e:0c:
7a:fd:15:f6:58:c8:64:b7:b5:61:1e:be:ed:22:07:
98:d0:c3:97:e8:0f:85:7b:e9:4b:53:a3:2e:e8:35:
38:cf:fc:08:19
coefficient:
41:f1:06:68:96:ed:6a:af:1b:2e:ee:a6:d9:56:0f:
a4:68:a0:d4:dc:81:c7:d8:bc:90:5f:c4:f8:90:bd:
65:26:21:ff:fe:67:86:9e:be:94:16:f1:71:e0:dc:
8a:33:ea:9c:a1:99:94:c6:12:e7:59:cf:2d:21:d0:
05:1a:9b:a2

$ openssl rsa -in rsa-enc-priv-xxx.pem -passin pass:test -text -noout
unable to load Private Key
140735192314332:error:0906D066:PEM routines:PEM_read_bio:bad end line:pem_lib.c:802:



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[Dave Thompson]

I was half wrong before.



The base64 read in EVP_Decode* allows 76. But the PEM parser in PEM_read_bio

enforces exactly 64 >>only for input files that have PEM-encrypt headers<<

which in practice is only encrypted legacy-format privatekey files.

(Nonprivate things like cert, CSR, publickey, params, etc. aren’t encrypted at all.

PKCS8 privatekey or PKCS12 key-plus-cert is encrypted within the ASN1, not as PEM.)



I have and know of no software to create encrypted legacy-format privatekeys

other than OpenSSL itself which always writes 64, so I never encountered this before.

(Other sw does do PKCS8-e or PKCS12 but see above.)



(As seen elsethread, OP apparently had PEM certs where PEM key was expected.)



From: owner-openssl-users-MCmKBN63+***@public.gmane.org [mailto:owner-openssl-users-MCmKBN63+***@public.gmane.org] On Behalf Of Jeffrey Walton
Sent: Tuesday, September 09, 2014 08:09
To: OpenSSL Users List
Subject: Re: cannot read PEM key file - no start line







On Sun, Sep 7, 2014 at 10:26 PM, Liz Fall <fall-***@public.gmane.org> wrote:

All,



I am getting the following with my client cert when trying to connect to an SSL-enabled MongoDB:



2014-09-03T13:37:56.881-0500 ERROR: cannot read PEM key file: /users/apps/tstlrn/u019807/DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem error:0906D06C:PEM routines:PEM_read_bio:no start line

I just tried to duplicate with a key (not a certificate) that uses line breaks at 76 characters. I don't have a certificate because my routines don't support certificates. But it should reveal a little about the OpenSSL parser.

Reading the public and private keys were OK when the line size was 76 (see below). So the OpenSSL parser is lenient during a read. This seems very reasonable to me.

Reading an encrypted private key resulted in an error "PEM_read_bio:bad end line:pem_lib.c:802" when the line size was 76 (see below). This kind of surprised me.

Since you are receiving the "no start line" error (and not another error), I would suspect you are reading an ASN.1/DER encoded certificate; and not a PEM encoded certificate. The error occured before anything related to line lengths.

<snip rest>

[Liz Fall]

Hi Dave,



Are you saying that the 76 characters per line is causing the problem with openSSL?



Thank you,

Liz



From: owner-openssl-users-MCmKBN63+***@public.gmane.org [mailto:owner-openssl-***@openssl.org] On Behalf Of Dave Thompson
Sent: Tuesday, September 09, 2014 5:49 PM
To: openssl-users-MCmKBN63+***@public.gmane.org
Subject: RE: cannot read PEM key file - no start line



I was half wrong before.



The base64 read in EVP_Decode* allows 76. But the PEM parser in PEM_read_bio

enforces exactly 64 >>only for input files that have PEM-encrypt headers<<

which in practice is only encrypted legacy-format privatekey files.

(Nonprivate things like cert, CSR, publickey, params, etc. aren’t encrypted at all.

PKCS8 privatekey or PKCS12 key-plus-cert is encrypted within the ASN1, not as PEM.)



I have and know of no software to create encrypted legacy-format privatekeys

other than OpenSSL itself which always writes 64, so I never encountered this before.

(Other sw does do PKCS8-e or PKCS12 but see above.)



(As seen elsethread, OP apparently had PEM certs where PEM key was expected.)



From: owner-openssl-users-MCmKBN63+***@public.gmane.org [mailto:owner-openssl-***@openssl.org] On Behalf Of Jeffrey Walton
Sent: Tuesday, September 09, 2014 08:09
To: OpenSSL Users List
Subject: Re: cannot read PEM key file - no start line







On Sun, Sep 7, 2014 at 10:26 PM, Liz Fall <fall-***@public.gmane.org> wrote:

All,



I am getting the following with my client cert when trying to connect to an SSL-enabled MongoDB:



2014-09-03T13:37:56.881-0500 ERROR: cannot read PEM key file: /users/apps/tstlrn/u019807/DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem error:0906D06C:PEM routines:PEM_read_bio:no start line

I just tried to duplicate with a key (not a certificate) that uses line breaks at 76 characters. I don't have a certificate because my routines don't support certificates. But it should reveal a little about the OpenSSL parser.

Reading the public and private keys were OK when the line size was 76 (see below). So the OpenSSL parser is lenient during a read. This seems very reasonable to me.

Reading an encrypted private key resulted in an error "PEM_read_bio:bad end line:pem_lib.c:802" when the line size was 76 (see below). This kind of surprised me.

Since you are receiving the "no start line" error (and not another error), I would suspect you are reading an ASN.1/DER encoded certificate; and not a PEM encoded certificate. The error occured before anything related to line lengths.

<snip rest>



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[Dave Thompson]

*If* you are now using a legacy-format encrypted private-key (and your original

error message suggested you might need some form of private key, which does

necessarily mean legacy-format encrypted) yes 76 chars is a problem.

The example(s) I saw earlier were certificates, where 76 chars works okay.



From: owner-openssl-users-MCmKBN63+***@public.gmane.org [mailto:owner-openssl-users-MCmKBN63+***@public.gmane.org] On Behalf Of Liz Fall
Sent: Wednesday, September 10, 2014 11:20
To: openssl-users-MCmKBN63+***@public.gmane.org
Subject: RE: cannot read PEM key file - no start line



Hi Dave,



Are you saying that the 76 characters per line is causing the problem with openSSL?



Thank you,

Liz



From: owner-openssl-users-MCmKBN63+***@public.gmane.org [mailto:owner-openssl-users-MCmKBN63+***@public.gmane.org] On Behalf Of Dave Thompson
Sent: Tuesday, September 09, 2014 5:49 PM
To: openssl-users-MCmKBN63+***@public.gmane.org
Subject: RE: cannot read PEM key file - no start line



I was half wrong before.



The base64 read in EVP_Decode* allows 76. But the PEM parser in PEM_read_bio

enforces exactly 64 >>only for input files that have PEM-encrypt headers<<

which in practice is only encrypted legacy-format privatekey files.

(Nonprivate things like cert, CSR, publickey, params, etc. aren’t encrypted at all.

PKCS8 privatekey or PKCS12 key-plus-cert is encrypted within the ASN1, not as PEM.)



I have and know of no software to create encrypted legacy-format privatekeys

other than OpenSSL itself which always writes 64, so I never encountered this before.

(Other sw does do PKCS8-e or PKCS12 but see above.)



(As seen elsethread, OP apparently had PEM certs where PEM key was expected.)



From: owner-openssl-users-MCmKBN63+***@public.gmane.org [mailto:owner-openssl-users-MCmKBN63+***@public.gmane.org] On Behalf Of Jeffrey Walton
Sent: Tuesday, September 09, 2014 08:09
To: OpenSSL Users List
Subject: Re: cannot read PEM key file - no start line







On Sun, Sep 7, 2014 at 10:26 PM, Liz Fall <fall-***@public.gmane.org> wrote:

All,



I am getting the following with my client cert when trying to connect to an SSL-enabled MongoDB:



2014-09-03T13:37:56.881-0500 ERROR: cannot read PEM key file: /users/apps/tstlrn/u019807/DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem error:0906D06C:PEM routines:PEM_read_bio:no start line

I just tried to duplicate with a key (not a certificate) that uses line breaks at 76 characters. I don't have a certificate because my routines don't support certificates. But it should reveal a little about the OpenSSL parser.

Reading the public and private keys were OK when the line size was 76 (see below). So the OpenSSL parser is lenient during a read. This seems very reasonable to me.

Reading an encrypted private key resulted in an error "PEM_read_bio:bad end line:pem_lib.c:802" when the line size was 76 (see below). This kind of surprised me.

Since you are receiving the "no start line" error (and not another error), I would suspect you are reading an ASN.1/DER encoded certificate; and not a PEM encoded certificate. The error occured before anything related to line lengths.

<snip rest>



_____


<http://www.avast.com/>

This email is free from viruses and malware because avast! Antivirus <http://www.avast.com/> protection is active.

[Viktor Dukhovni]

Post by Dave Thompson
*If* you are now using a legacy-format encrypted private-key (and your original
error message suggested you might need some form of private key, which does
necessarily mean legacy-format encrypted) yes 76 chars is a problem.

That said, it seems more likely that the real issue is that client
code should be attempting to employ a client certificate file.
The OP provided a file with no client private key (there is none),
and the software complains since no private key of any kind is
found.

The client key file should be initialized to NULL. Separately
the client may need to specify trust anchors so that server
validation succeeds.

However, when it comes to X.509 PKI, the OP may be "in a maze of
twisty little passages, all alike". I don't know how to bridge
the gulf. Some sort of tutorial may be the a start. Any
recommendations of a gentle introduction to X.509 certificates,
keys, trust anchors, ... for operators and developers?

[Liz Fall]

Hi Victor,

I did specify the client key file to NULL. Then, I authenticated the client
with a user id and password. That worked.

Why would the file not have a client private key?

Thanks for your help.
Liz

-----Original Message-----
From: owner-openssl-users-MCmKBN63+***@public.gmane.org
[mailto:owner-openssl-users-MCmKBN63+***@public.gmane.org] On Behalf Of Viktor Dukhovni
Sent: Friday, September 12, 2014 7:39 AM
To: openssl-users-MCmKBN63+***@public.gmane.org
Subject: Re: cannot read PEM key file - no start line

Post by Dave Thompson
*If* you are now using a legacy-format encrypted private-key (and your original
error message suggested you might need some form of private key, which does
necessarily mean legacy-format encrypted) yes 76 chars is a problem.

That said, it seems more likely that the real issue is that client code
should be attempting to employ a client certificate file.
The OP provided a file with no client private key (there is none), and the
software complains since no private key of any kind is found.

The client key file should be initialized to NULL. Separately the client
may need to specify trust anchors so that server validation succeeds.

However, when it comes to X.509 PKI, the OP may be "in a maze of twisty
little passages, all alike". I don't know how to bridge the gulf. Some
sort of tutorial may be the a start. Any recommendations of a gentle
introduction to X.509 certificates, keys, trust anchors, ... for operators
and developers?
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Viktor Dukhovni]

Post by Liz Fall
I did specify the client key file to NULL. Then, I authenticated the client
with a user id and password. That worked.

Good. I think it is best to stop there for now.

Post by Liz Fall
Why would the file not have a client private key?

[ No such key is necessary, available or placed by you in the file. ]

I'm afraid a public mailing list is not a good substitute for a
good book. Find a good book on programming with SSL/TLS that spends
adequate time on background material, and not just code samples.

[Liz Fall]

Thank you, Viktor. Do you have a good recommendation?

Thanks,
Liz

-----Original Message-----
From: owner-openssl-users-MCmKBN63+***@public.gmane.org
[mailto:owner-openssl-users-MCmKBN63+***@public.gmane.org] On Behalf Of Viktor Dukhovni
Sent: Saturday, September 13, 2014 9:21 PM
To: openssl-users-MCmKBN63+***@public.gmane.org
Subject: Re: cannot read PEM key file - no start line

Post by Liz Fall
I did specify the client key file to NULL. Then, I authenticated the
client with a user id and password. That worked.

Good. I think it is best to stop there for now.

Post by Liz Fall
Why would the file not have a client private key?

[ No such key is necessary, available or placed by you in the file. ]

I'm afraid a public mailing list is not a good substitute for a good book.
Find a good book on programming with SSL/TLS that spends adequate time on
background material, and not just code samples.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Viktor Dukhovni]

Post by Liz Fall
Thank you, Viktor. Do you have a good recommendation?

Sorry, have not read any myself. Got there over a couple of decades
via a different path, but I am under the impression that at least
one decent book on the subject is available.

[Michael Wojcik]

Sent: Sunday, 14 September, 2014 00:33
Subject: RE: cannot read PEM key file - no start line
Thank you, Viktor. Do you have a good recommendation?

In the past I've recommended Eric Rescorla's /SSL and TLS: Designing and Building Secure Systems/. It's quite old now but most of the material is still relevant even to TLS 1.2 - and of course many applications are running old versions of SSL and TLS implementations in any case.

It's dry, but Rescorla does a good job of covering both design and implementation details. And he knows his stuff - he's one of the authors of the TLS RFCs.
--
Michael Wojcik
Technology Specialist, Micro Focus



This message has been scanned for malware by Websense. www.websense.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Liz Fall]

Thanks for the recommendations, Michael.

Liz

-----Original Message-----
From: owner-openssl-users-MCmKBN63+***@public.gmane.org
[mailto:owner-openssl-users-MCmKBN63+***@public.gmane.org] On Behalf Of Michael Wojcik
Sent: Sunday, September 14, 2014 5:28 AM
To: openssl-users-MCmKBN63+***@public.gmane.org
Subject: RE: cannot read PEM key file - no start line

Sent: Sunday, 14 September, 2014 00:33
Subject: RE: cannot read PEM key file - no start line
Thank you, Viktor. Do you have a good recommendation?

In the past I've recommended Eric Rescorla's /SSL and TLS: Designing and
Building Secure Systems/. It's quite old now but most of the material is
still relevant even to TLS 1.2 - and of course many applications are running
old versions of SSL and TLS implementations in any case.

It's dry, but Rescorla does a good job of covering both design and
implementation details. And he knows his stuff - he's one of the authors of
the TLS RFCs.

--
Michael Wojcik
Technology Specialist, Micro Focus



This message has been scanned for malware by Websense. www.websense.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Dave Thompson]

Sent: Friday, September 12, 2014 04:31
*If* you are now using a legacy-format encrypted private-key (and your original
error message suggested you might need some form of private key, which does
necessarily mean legacy-format encrypted) yes 76 chars is a problem.
The example(s) I saw earlier were certificates, where 76 chars works okay.

Argh! private key does NOT necessarily mean legacy-format encrypted.
If you need encrypted PEM private key (and that remains a separate question)
you can use PKCS#8 PEM private key with any width base64 up to 76.
On general principles PKCS#8 is preferably to legacy anyway; it's more
standard/interoperatble, more flexible, the encryption is better.


______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Jeffrey Walton]

Post by Dave Thompson
...
I have and know of no software to create encrypted legacy-format privatekeys
other than OpenSSL itself which always writes 64, so I never encountered this before.

You can use Crypto++ with the PEM Pack
(http://www.cryptopp.com/wiki/PEM_Pack). Its an add-on, and not part
of the library proper. Just unzip it into the Crypto++ sources and
build the library as usual (the makefile will pick up the new sources
automatically).

The line length is hard coded at 64 per RFC 1421, but it can be
changed. To change it, open pem-com.h (PEM common) and change the
following on line 87:

// 64-character line length is required by RFC 1421 and used by OpenSSL.
static const unsigned int OPENSSL_B64_LINE_BREAK = 64;

Jeff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org