Re: [openssl-users] scripting creating a cert

[Robert Moskowitz]

Viktor,

On 03/09/2017 05:53 PM, Viktor Dukhovni wrote:

On Mar 9, 2017, at 8:43 PM, Robert Moskowitz  wrote:


   $ umask 077 # avoid world-readable private keys

Perhaps (no perhaps about it) this is old information, but I picked up that I 
needed:

chmod 640 for the private keys for Apache.  (and postfix and others use these 
certs; at least they are in their confs)

I strive to avoid the private disclosure race of first creating
a world-readable file, and then trying to do a quick chmod before
the bad guys get around to opening it.  That's why I recommend the
umask approach.

You can adjust the umask to suit your needs.  With OpenSSL 1.1.0,
if I recall correctly "keyout" files and the like are automatically
opened mode "0600". Rich Salz, who wrote the CLI option processing
code for 1.1.0 will correct me, if my memory if faulty.  There are
still a lot of users with 1.0.2 or earlier, and OpenSSL cannot
always figure out which files end up having private keys in them,
so the umask approach is a good precaution to keep using.


Rich got me some help and I have put the following together:

Set the following variables:

countryName=
stateOrProvinceName=
localityName=
organizationName=
organizationalUnitName=
emailAddress=postmaster@$your_domain_tld

Then the following commands create the certs:

restore_mask=$(umask -p)
umask 077
cd /etc/pki/tls
commonName=$your_host_tld

openssl req -new -outform PEM -out certs/$commonName.crt -newkey 
rsa:2048 -nodes -keyout private/$commonName.key -keyform PEM -days 3650 
-x509 -extensions v3_req -subj 
"/countryName=$countryName/stateOrProvinceName=$stateOrProvinceName/localityName=$localityName/organizationName=$organizationName/organizationalUnitName=$organizationalUnitName/commonName=$commonName/emailAddress=$emailAddress"


chmod 640 private/$commonName.key
commonName=webmail$your_domain_tld

openssl req -new -outform PEM -out certs/$commonName.crt -newkey 
rsa:2048 -nodes -keyout private/$commonName.key -keyform PEM -days 3650 
-x509 -extensions v3_req -subj 
"/countryName=$countryName/stateOrProvinceName=$stateOrProvinceName/localityName=$localityName/organizationName=$organizationName/organizationalUnitName=$organizationalUnitName/commonName=$commonName/emailAddress=$emailAddress"


chmod 640 private/$commonName.key
commonName=localhost

openssl req -new -outform PEM -out certs/$commonName.crt -newkey 
rsa:2048 -nodes -keyout private/$commonName.key -keyform PEM -days 3650 
-x509 -extensions v3_req -subj 
"/countryName=$countryName/stateOrProvinceName=$stateOrProvinceName/localityName=$localityName/organizationName=$organizationName/organizationalUnitName=$organizationalUnitName/commonName=$commonName/emailAddress=$emailAddress"


chmod 640 private/$commonName.key
$restore_mask


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Extracting Handshake Information

[Dr. Stephen Henson]

On Tue, Mar 14, 2017, Vijayakumar Kaliaperumal wrote:

> Hello,
> 
> Is there a way in openssl we can extract the protocol(TLS/DTLS ) handshake
> information, like in clienthello,  the protocol version, ciphersuites
> offered, Random,  session id etc.
> 

You can get some useful information with the -trace option to
s_client/s_server which needs the configuration option enable-ssl-trace

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Extracting Handshake Information

[Salz, Rich via openssl-users]

> Is there a way in openssl we can extract the protocol(TLS/DTLS ) handshake 
> information, like in clienthello,  the protocol version, ciphersuites 
> offered, Random,  session id etc.

Look at the code in apps/s_client and apps/s_server and see what it prints in 
various debug modes.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Extracting Handshake Information

[Vijayakumar Kaliaperumal]

Hello,

Is there a way in openssl we can extract the protocol(TLS/DTLS ) handshake
information, like in clienthello,  the protocol version, ciphersuites
offered, Random,  session id etc.

Regards,
Vijay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cannot read exported PKCS12 cert and private key

[Gary L Peskin]

Thanks again.  Very clear.  I’m thinking maybe of a small utility or even a web 
site were you could upload the thing and it would tell you what it was looking 
it.  I’ll add that to my never-ending to do list on the off chance that I’ll 
ever have spare time.

 

Gary

 

 

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Michael Wojcik
Sent: Monday, March 13, 2017 11:05 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Cannot read exported PKCS12 cert and private key

 

Glad I could help. To be honest, I had to play around with it for a bit before 
I remembered that RACF can export PEM-encoded PKCS#12, and how I had handled 
that the last time I went through this myself.

 

Also, having experience with figuring out what a file is using openssl 
asn1parse definitely helps. The last time I taught a class on key and 
certificate handling, we did an entire exercise on this, because we're always 
getting this sort of thing from customers. "Here's a zip with our key and 
certificate files", they say, and then there are files in it with names like 
"file0" and "key1", and it turns out "key1" is actually a certificate. Learning 
how to match private keys to certificates is also very useful; I actually ended 
up giving one customer a script to do that, because they'd been copying things 
from machine to machine and had really confused the situation.

 

Someone needs to write a book like Surviving Cryptography with OpenSSL that 
covers these things, along the lines of Ivan Ristić's OpenSSL Cookbook. (I'd 
volunteer but to be honest it'd never get done.) I guess this sort of thing 
should go on the wiki; maybe some of it's there already.

 

Anyway, back on the subject: I suppose technically this is not really PEM 
encoding, because the PEM delimiters lie. "- BEGIN CERTIFICATE -" 
claims that what follows is a Base64-encoded DER-encoded X.509 certificate, not 
a Base64-encoded DER-encoded PKCS#12 structure. Those are rather different 
things. I suspect RACF supports this because 1) it was easy and 2) it's 
convenient to have a text representation (that converts cleanly between EBCDIC 
and ASCII). But it's not technically correct.

 

That's probably why OpenSSL doesn't support it; fake-PEM-PKCS#12 is a RACF 
idiosyncracy, as far as I know. I'm guessing Windows just takes whatever's 
between the PEM delimiters, decodes the Base64, parses it as ASN.1 DER, and 
then decides what to do.

 

You could argue, by Postel's Interoperability Principle, that openssl should 
have a "-figure-out-the-format" option for every command that takes files. On 
the other hand, the Interoperability Principle is a security risk; many 
vulnerabilities are eliminated simply by requiring inputs that satisfy the 
specification.

 

With a decent scripting language it's pretty easy to recognize one of these 
files and automatically extract it into something sensible.

 

 

Michael Wojcik 
Distinguished Engineer, Micro Focus 

 

 

 

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Gary L Peskin
Sent: Monday, March 13, 2017 10:26
To: openssl-users@openssl.org  
Subject: Re: [openssl-users] Cannot read exported PKCS12 cert and private key

 

Thanks VERY much Michael.  That did the trick.  This was a homegrown CA cert 
and I needed it to sign a certificate request for testing purposes.

 

I didn’t realize that the openssl pkcs12 utility didn’t support PEM encoding 
for input.  I was a little confused I guess by the documentation which shows 
PEM encoding for “-in filename” but I see now that that’s for when exporting a 
PKCS#12 file, not for parsing one.

 

Thanks again for clearing this up.  It’s weird that MS supports this input 
format but openssl does not. I thought openssl could do EVERYTHING.  

 

 

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cannot read exported PKCS12 cert and private key

[Michael Wojcik]

Glad I could help. To be honest, I had to play around with it for a bit before 
I remembered that RACF can export PEM-encoded PKCS#12, and how I had handled 
that the last time I went through this myself.

Also, having experience with figuring out what a file is using openssl 
asn1parse definitely helps. The last time I taught a class on key and 
certificate handling, we did an entire exercise on this, because we're always 
getting this sort of thing from customers. "Here's a zip with our key and 
certificate files", they say, and then there are files in it with names like 
"file0" and "key1", and it turns out "key1" is actually a certificate. Learning 
how to match private keys to certificates is also very useful; I actually ended 
up giving one customer a script to do that, because they'd been copying things 
from machine to machine and had really confused the situation.

Someone needs to write a book like Surviving Cryptography with OpenSSL that 
covers these things, along the lines of Ivan Ristić's OpenSSL Cookbook. (I'd 
volunteer but to be honest it'd never get done.) I guess this sort of thing 
should go on the wiki; maybe some of it's there already.
Anyway, back on the subject: I suppose technically this is not really PEM 
encoding, because the PEM delimiters lie. "- BEGIN CERTIFICATE -" 
claims that what follows is a Base64-encoded DER-encoded X.509 certificate, not 
a Base64-encoded DER-encoded PKCS#12 structure. Those are rather different 
things. I suspect RACF supports this because 1) it was easy and 2) it's 
convenient to have a text representation (that converts cleanly between EBCDIC 
and ASCII). But it's not technically correct.

That's probably why OpenSSL doesn't support it; fake-PEM-PKCS#12 is a RACF 
idiosyncracy, as far as I know. I'm guessing Windows just takes whatever's 
between the PEM delimiters, decodes the Base64, parses it as ASN.1 DER, and 
then decides what to do.

You could argue, by Postel's Interoperability Principle, that openssl should 
have a "-figure-out-the-format" option for every command that takes files. On 
the other hand, the Interoperability Principle is a security risk; many 
vulnerabilities are eliminated simply by requiring inputs that satisfy the 
specification.

With a decent scripting language it's pretty easy to recognize one of these 
files and automatically extract it into something sensible.


Michael Wojcik
Distinguished Engineer, Micro Focus



From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Gary L Peskin
Sent: Monday, March 13, 2017 10:26
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Cannot read exported PKCS12 cert and private key

Thanks VERY much Michael.  That did the trick.  This was a homegrown CA cert 
and I needed it to sign a certificate request for testing purposes.

I didn’t realize that the openssl pkcs12 utility didn’t support PEM encoding 
for input.  I was a little confused I guess by the documentation which shows 
PEM encoding for “-in filename” but I see now that that’s for when exporting a 
PKCS#12 file, not for parsing one.

Thanks again for clearing this up.  It’s weird that MS supports this input 
format but openssl does not. I thought openssl could do EVERYTHING.  


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cannot read exported PKCS12 cert and private key

[Kyle Hamilton]

Enhancement request:

make 'pkcs12' support -inform and -outform.

On Mon, Mar 13, 2017 at 9:26 AM, Gary L Peskin  wrote:

> Thanks VERY much Michael.  That did the trick.  This was a homegrown CA
> cert and I needed it to sign a certificate request for testing purposes.
>
>
>
> I didn’t realize that the openssl pkcs12 utility didn’t support PEM
> encoding for input.  I was a little confused I guess by the documentation
> which shows PEM encoding for “-in filename” but I see now that that’s for
> when exporting a PKCS#12 file, not for parsing one.
>
>
>
> Thanks again for clearing this up.  It’s weird that MS supports this input
> format but openssl does not. I thought openssl could do EVERYTHING.  
>
>
>
> Thanks,
>
> Gary
>
>
>
> *From:* openssl-users [mailto:openssl-users-boun...@openssl.org] *On
> Behalf Of *Michael Wojcik
> *Sent:* Monday, March 13, 2017 8:58 AM
>
> *To:* openssl-users@openssl.org
> *Subject:* Re: [openssl-users] Cannot read exported PKCS12 cert and
> private key
>
>
>
> I'll assume you mean you exported it "from a mainframe system" using RACF.
> RACF has half a dozen export formats for certificates and keys; they're not
> all supported by OpenSSL.
>
>
>
> In particular (and despite the PEM delimiters), I suspect what you have
> here is a PKCS#12 file in PEM format. The openssl pkcs12 utility doesn't
> support PEM encoding, because that's not normally done. RACF will do it,
> though, just to be difficult.
>
>
>
> openssl asn1parse -in *file* -inform pem shows you have valid ASN.1 data,
> with a big ol' blob at offset 26; adding -strparse 26 shows encrypted data.
> So yes, looks like PKCS#12.
>
>
>
> So, try this:
>
> 1. Edit the file and remove the PEM delimiters (" BEGIN CERTIFICATE
> " and "- END CERTIFICATE ").
>
> 2. Convert the data from Base64 to binary:
> openssl base64 -d -in *file* -out *file.der*
>
> 3. Unpack it:
>
> openssl pkcs12 -in *file*.der -nokeys -out *file*-cert.pem
>
> openssl pkcs12 -in *file*.der -nocerts -out *file*-key.pem
>
>
>
> Note the final openssl command will prompt you for the password to encrypt
> the key file with; if you don't want your private key encrypted, you can
> also specify -nodes.
>
>
>
> You can use openssl pkcs12 just once, without the -nokeys / -nocerts
> options, but that will put your certificate and key in the same file, which
> is generally not what you want with OpenSSL.
>
>
>
> Of course, you haven't told us what you're trying to do, so I'm just
> guessing.
>
>
>
> Also, I can't verify this, because I don't have the import password for
> your PKCS#12 file.
>
>
>
>
>
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>
>
>
>
>
> *From:* openssl-users [mailto:openssl-users-boun...@openssl.org
> ] *On Behalf Of *Gary L Peskin
> *Sent:* Monday, March 13, 2017 08:39
> *To:* openssl-users@openssl.org
> *Subject:* Re: [openssl-users] Cannot read exported PKCS12 cert and
> private key
>
>
>
> My original message accidently included an attachment.  Please ignore the
> attachment.  That was not related to this issue.
>
>
>
> Thanks,
>
> Gary
>
>
>
> *From:* Gary L Peskin [mailto:ga...@firstech.com ]
> *Sent:* Monday, March 13, 2017 2:28 AM
> *To:* 'openssl-users@openssl.org' 
> *Subject:* Cannot read exported PKCS12 cert and private key
>
>
>
> Hello all
>
>
>
> I exported a certificate and corresponding private key in base 64 encoded
> DER format from a mainframe system and FTP’d it to my Windows desktop.
>
>
>
> I tried to read it using OpenSSL 1.0.2.k and 1.1.0d 32-bit and 64-bit on
> Windows with
>
>
>
> openssl pkcs12  -in mycert.p12  -noout
>
>
>
> But I get the following messages:
>
>
>
> 15956:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong
> tag:.\crypto\asn1\tasn_dec.c:1199:
>
> 15956:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1
> error:.\crypto\asn1\tasn_dec.c:374:Type=PKCS12
>
>
>
> I’m able to import this with the private key into the Windows certificate
> store with no issues.
>
>
>
> Can someone please advise as to what I’m doing wrong?
>
>
>
> Thanks,
>
> Gary
>
>
>
> PS Here is the file:
>
>
>
> -BEGIN CERTIFICATE-
>
> MIIKCAIBAzCCCcQGCSqGSIb3DQEHAaCCCbUEggmxMIIJrTCCBE8GCSqGSIb3DQEH
>
> BqCCBEAwggQ8AgEAMIIENQYJKoZIhvcNAQcBMBwGCiqGSIb3DQEMAQMwDgQIjdBS
>
> +TZF+xQCAgP5gIIECNtJIUg23ab7AXi33MKueO03S1pUkHCQk+kByNK/6f1FgEvu
>
> XRqhniR3mdyzeMVBCrCBSx3GhZlpLcW/d6OAd3z8hbXjvw5OC5OLavemfRNtsi+R
>
> q9LggkcWT2oCszc2nglKzHYaFnkG80vwxLwUXmROL+UK4ZlYmqp46EjuNAEo/yqQ
>
> yEwgia3iP84wiZRfY9kBJMq9yUm+LvowO/1E9v/ycgE6IWe1CrThQzrD6Vm9LaTy
>
> 0oZqAbTbzbedZwGsuWZoedw2FtmRijkH5EbRNRpTrUUO/qQMO19v5IKtd4kUAWea
>
> dpYrwn1kkD2aInKKsjycCFtGopXPbmrqj2cm335cESN4XePBHQuzaywHgd0WjU5O
>
> ++UM+B/5Kpx3af53E412pGAcgnPH/ZQKMa5Zkp73pcFmViLEC7Tn9eNB2iNUfX9p
>
> rV3RNRnrEPZlD1MuYEkmBIWA5czUiDKrpyYA1fmrSsFthFMhD5fTVoDMSTBmNXPz
>
> 

Re: [openssl-users] Cannot read exported PKCS12 cert and private key

[Gary L Peskin]

Thanks VERY much Michael.  That did the trick.  This was a homegrown CA cert 
and I needed it to sign a certificate request for testing purposes.

 

I didn’t realize that the openssl pkcs12 utility didn’t support PEM encoding 
for input.  I was a little confused I guess by the documentation which shows 
PEM encoding for “-in filename” but I see now that that’s for when exporting a 
PKCS#12 file, not for parsing one.

 

Thanks again for clearing this up.  It’s weird that MS supports this input 
format but openssl does not. I thought openssl could do EVERYTHING.  

 

Thanks,

Gary

 

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Michael Wojcik
Sent: Monday, March 13, 2017 8:58 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Cannot read exported PKCS12 cert and private key

 

I'll assume you mean you exported it "from a mainframe system" using RACF. RACF 
has half a dozen export formats for certificates and keys; they're not all 
supported by OpenSSL.

 

In particular (and despite the PEM delimiters), I suspect what you have here is 
a PKCS#12 file in PEM format. The openssl pkcs12 utility doesn't support PEM 
encoding, because that's not normally done. RACF will do it, though, just to be 
difficult.

 

openssl asn1parse -in file -inform pem shows you have valid ASN.1 data, with a 
big ol' blob at offset 26; adding -strparse 26 shows encrypted data. So yes, 
looks like PKCS#12.

 

So, try this:

1. Edit the file and remove the PEM delimiters (" BEGIN CERTIFICATE " 
and "- END CERTIFICATE ").

2. Convert the data from Base64 to binary:
openssl base64 -d -in file -out file.der

3. Unpack it:

openssl pkcs12 -in file.der -nokeys -out file-cert.pem

openssl pkcs12 -in file.der -nocerts -out file-key.pem

 

Note the final openssl command will prompt you for the password to encrypt the 
key file with; if you don't want your private key encrypted, you can also 
specify -nodes.

 

You can use openssl pkcs12 just once, without the -nokeys / -nocerts options, 
but that will put your certificate and key in the same file, which is generally 
not what you want with OpenSSL.

 

Of course, you haven't told us what you're trying to do, so I'm just guessing.

 

Also, I can't verify this, because I don't have the import password for your 
PKCS#12 file.

 

 

Michael Wojcik 
Distinguished Engineer, Micro Focus 

 

 

 

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Gary L Peskin
Sent: Monday, March 13, 2017 08:39
To: openssl-users@openssl.org  
Subject: Re: [openssl-users] Cannot read exported PKCS12 cert and private key

 

My original message accidently included an attachment.  Please ignore the 
attachment.  That was not related to this issue.

 

Thanks,

Gary

 

From: Gary L Peskin [mailto:ga...@firstech.com] 
Sent: Monday, March 13, 2017 2:28 AM
To: 'openssl-users@openssl.org'  >
Subject: Cannot read exported PKCS12 cert and private key

 

Hello all

 

I exported a certificate and corresponding private key in base 64 encoded DER 
format from a mainframe system and FTP’d it to my Windows desktop.

 

I tried to read it using OpenSSL 1.0.2.k and 1.1.0d 32-bit and 64-bit on 
Windows with 

 

openssl pkcs12  -in mycert.p12  -noout

 

But I get the following messages:

 

15956:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong 
tag:.\crypto\asn1\tasn_dec.c:1199:

15956:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 
error:.\crypto\asn1\tasn_dec.c:374:Type=PKCS12

 

I’m able to import this with the private key into the Windows certificate store 
with no issues.

 

Can someone please advise as to what I’m doing wrong?

 

Thanks,

Gary

 

PS Here is the file:

 

-BEGIN CERTIFICATE-

MIIKCAIBAzCCCcQGCSqGSIb3DQEHAaCCCbUEggmxMIIJrTCCBE8GCSqGSIb3DQEH

BqCCBEAwggQ8AgEAMIIENQYJKoZIhvcNAQcBMBwGCiqGSIb3DQEMAQMwDgQIjdBS

+TZF+xQCAgP5gIIECNtJIUg23ab7AXi33MKueO03S1pUkHCQk+kByNK/6f1FgEvu

XRqhniR3mdyzeMVBCrCBSx3GhZlpLcW/d6OAd3z8hbXjvw5OC5OLavemfRNtsi+R

q9LggkcWT2oCszc2nglKzHYaFnkG80vwxLwUXmROL+UK4ZlYmqp46EjuNAEo/yqQ

yEwgia3iP84wiZRfY9kBJMq9yUm+LvowO/1E9v/ycgE6IWe1CrThQzrD6Vm9LaTy

0oZqAbTbzbedZwGsuWZoedw2FtmRijkH5EbRNRpTrUUO/qQMO19v5IKtd4kUAWea

dpYrwn1kkD2aInKKsjycCFtGopXPbmrqj2cm335cESN4XePBHQuzaywHgd0WjU5O

++UM+B/5Kpx3af53E412pGAcgnPH/ZQKMa5Zkp73pcFmViLEC7Tn9eNB2iNUfX9p

rV3RNRnrEPZlD1MuYEkmBIWA5czUiDKrpyYA1fmrSsFthFMhD5fTVoDMSTBmNXPz

5B8HYW4+aDbo7N2a+BtFNcbMqYJqYwVL7xE2rL6nUedMyN2uKeZfOnLLQuYoUCg7

iYO5k7D/jQNsviyZg022Nzwy4agdPBKqok8oanQge8/pr3NeMrNDDKVyWy8ZBVBv

KGi3qaX45ejJxP8XaJxxw88+KOc1OvAMhWhAHlHqpw9d7OiAP1oCV+vRuYnD5N9a

YyLspoKy1nk+Htl71QQ4GYCRRGXMl7YsxtRrUSOAZa2+V/5h6ljUsTsib3VhO0eL

/jf+BlBxhpWw1J9L0r6sFMYvVS3AsqfqnBLJUFLxeQxYvVsV0Gpx8BonpZACQC91

DB4oV0l6whqtAQ4dJMJEk9nNnP0NYsVceKybF5NvgL3lzALw/Ezv8K7Y69FJaM35

Re: [openssl-users] Cannot read exported PKCS12 cert and private key

[Michael Wojcik]

I'll assume you mean you exported it "from a mainframe system" using RACF. RACF 
has half a dozen export formats for certificates and keys; they're not all 
supported by OpenSSL.

In particular (and despite the PEM delimiters), I suspect what you have here is 
a PKCS#12 file in PEM format. The openssl pkcs12 utility doesn't support PEM 
encoding, because that's not normally done. RACF will do it, though, just to be 
difficult.

openssl asn1parse -in file -inform pem shows you have valid ASN.1 data, with a 
big ol' blob at offset 26; adding -strparse 26 shows encrypted data. So yes, 
looks like PKCS#12.

So, try this:
1. Edit the file and remove the PEM delimiters (" BEGIN CERTIFICATE " 
and "- END CERTIFICATE ").
2. Convert the data from Base64 to binary:
openssl base64 -d -in file -out file.der
3. Unpack it:
openssl pkcs12 -in file.der -nokeys -out file-cert.pem
openssl pkcs12 -in file.der -nocerts -out file-key.pem

Note the final openssl command will prompt you for the password to encrypt the 
key file with; if you don't want your private key encrypted, you can also 
specify -nodes.

You can use openssl pkcs12 just once, without the -nokeys / -nocerts options, 
but that will put your certificate and key in the same file, which is generally 
not what you want with OpenSSL.

Of course, you haven't told us what you're trying to do, so I'm just guessing.

Also, I can't verify this, because I don't have the import password for your 
PKCS#12 file.


Michael Wojcik
Distinguished Engineer, Micro Focus



From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Gary L Peskin
Sent: Monday, March 13, 2017 08:39
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Cannot read exported PKCS12 cert and private key

My original message accidently included an attachment.  Please ignore the 
attachment.  That was not related to this issue.

Thanks,
Gary

From: Gary L Peskin [mailto:ga...@firstech.com]
Sent: Monday, March 13, 2017 2:28 AM
To: 'openssl-users@openssl.org' 
>
Subject: Cannot read exported PKCS12 cert and private key

Hello all

I exported a certificate and corresponding private key in base 64 encoded DER 
format from a mainframe system and FTP’d it to my Windows desktop.

I tried to read it using OpenSSL 1.0.2.k and 1.1.0d 32-bit and 64-bit on 
Windows with

openssl pkcs12  -in mycert.p12  -noout

But I get the following messages:

15956:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong 
tag:.\crypto\asn1\tasn_dec.c:1199:
15956:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 
error:.\crypto\asn1\tasn_dec.c:374:Type=PKCS12

I’m able to import this with the private key into the Windows certificate store 
with no issues.

Can someone please advise as to what I’m doing wrong?

Thanks,
Gary

PS Here is the file:

-BEGIN CERTIFICATE-
MIIKCAIBAzCCCcQGCSqGSIb3DQEHAaCCCbUEggmxMIIJrTCCBE8GCSqGSIb3DQEH
BqCCBEAwggQ8AgEAMIIENQYJKoZIhvcNAQcBMBwGCiqGSIb3DQEMAQMwDgQIjdBS
+TZF+xQCAgP5gIIECNtJIUg23ab7AXi33MKueO03S1pUkHCQk+kByNK/6f1FgEvu
XRqhniR3mdyzeMVBCrCBSx3GhZlpLcW/d6OAd3z8hbXjvw5OC5OLavemfRNtsi+R
q9LggkcWT2oCszc2nglKzHYaFnkG80vwxLwUXmROL+UK4ZlYmqp46EjuNAEo/yqQ
yEwgia3iP84wiZRfY9kBJMq9yUm+LvowO/1E9v/ycgE6IWe1CrThQzrD6Vm9LaTy
0oZqAbTbzbedZwGsuWZoedw2FtmRijkH5EbRNRpTrUUO/qQMO19v5IKtd4kUAWea
dpYrwn1kkD2aInKKsjycCFtGopXPbmrqj2cm335cESN4XePBHQuzaywHgd0WjU5O
++UM+B/5Kpx3af53E412pGAcgnPH/ZQKMa5Zkp73pcFmViLEC7Tn9eNB2iNUfX9p
rV3RNRnrEPZlD1MuYEkmBIWA5czUiDKrpyYA1fmrSsFthFMhD5fTVoDMSTBmNXPz
5B8HYW4+aDbo7N2a+BtFNcbMqYJqYwVL7xE2rL6nUedMyN2uKeZfOnLLQuYoUCg7
iYO5k7D/jQNsviyZg022Nzwy4agdPBKqok8oanQge8/pr3NeMrNDDKVyWy8ZBVBv
KGi3qaX45ejJxP8XaJxxw88+KOc1OvAMhWhAHlHqpw9d7OiAP1oCV+vRuYnD5N9a
YyLspoKy1nk+Htl71QQ4GYCRRGXMl7YsxtRrUSOAZa2+V/5h6ljUsTsib3VhO0eL
/jf+BlBxhpWw1J9L0r6sFMYvVS3AsqfqnBLJUFLxeQxYvVsV0Gpx8BonpZACQC91
DB4oV0l6whqtAQ4dJMJEk9nNnP0NYsVceKybF5NvgL3lzALw/Ezv8K7Y69FJaM35
LrT9JlGSt/BJ0oXp4wxqH4UbHikhGpSCteh7k3ZQkbE4fokVhH9lYkMXqBRXqXlI
nV9b7hR26NeJY0C7a9VyNXtzIVsP+JiBhDzc7GDafIF99fUHPVfqh15CPnTb5liZ
A6QlYw1aVvyhS8ST4I117kALKWUdl9xhe+ui0IFCEQY/mNuQ8O13nlcx+DvGtPxc
WCUG0VpP6AkE9Mkd67CghF6sFh/8FqdE1jU2Asj+iCZVU/s0ngH3hAXwMVUwOW9S
voxYParz1b0sF7vgrhLteHOZ03TEra7rh7OiOVUCOE6CACG1qV8QXDvpkZp2mGTx
5T7ob8nNF8XQWhIHjULVdKdOBuMh/4dOrHTuU5cFosR29mbzAZDDi0myuzTv37GJ
OgyiX0XXvwn5jCmAoaE0ji1fgxrWUs8yVYYHOj3IyQwzU+FydfKtlnhh8ZxHKDBo
8wPqrEAzTXT49bsxvy3cYxUp4Dd1G2ymkoTZonEi7Vir0kN7qjCCBVYGCSqGSIb3
DQEHAaCCBUcEggVDMIIFPzCCBTsGCyqGSIb3DQEMCgECoIIE7jCCBOowHAYKKoZI
hvcNAQwBAzAOBAh2oqSgVyE4cwICA/EEggTInCkEbWknH/Vojqzmn1jIPRGb7dG+
egxS5YDtk14LxnQuwACTQef2wQnKlosYbfH8dJVIvXRYB19MXroGpd5KJA8Dftqa
dWFVAcDIrzV/ZS252aita0fKOVeqjKWo7TkA9jnwDeekAcK+1R5ioIcfXPLJDSUX
gdEaza88oQ+g+34+B2o+mnTPT/PM/o1n6cifVRURn2jMASwiB/cwLn58UZibCSgL
h3CrcKamWi8AF3eJ2rkpPuK41s8SfqZ1ByNEFSgnsX5UQzJpn8FoBPBOmFnR8FTr
XNwtT7GcJJuWDSnf+On2PI2LYT6XAhNeCkfMwdnUa6N1YV2Okelmae4J21sldQlw

Re: [openssl-users] Cannot read exported PKCS12 cert and private key

[Gary L Peskin]

My original message accidently included an attachment.  Please ignore the
attachment.  That was not related to this issue.

 

Thanks,

Gary

 

From: Gary L Peskin [mailto:ga...@firstech.com] 
Sent: Monday, March 13, 2017 2:28 AM
To: 'openssl-users@openssl.org' 
Subject: Cannot read exported PKCS12 cert and private key

 

Hello all

 

I exported a certificate and corresponding private key in base 64 encoded
DER format from a mainframe system and FTP'd it to my Windows desktop.

 

I tried to read it using OpenSSL 1.0.2.k and 1.1.0d 32-bit and 64-bit on
Windows with 

 

openssl pkcs12  -in mycert.p12  -noout

 

But I get the following messages:

 

15956:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong
tag:.\crypto\asn1\tasn_dec.c:1199:

15956:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1
error:.\crypto\asn1\tasn_dec.c:374:Type=PKCS12

 

I'm able to import this with the private key into the Windows certificate
store with no issues.

 

Can someone please advise as to what I'm doing wrong?

 

Thanks,

Gary

 

PS Here is the file:

 

-BEGIN CERTIFICATE-

MIIKCAIBAzCCCcQGCSqGSIb3DQEHAaCCCbUEggmxMIIJrTCCBE8GCSqGSIb3DQEH

BqCCBEAwggQ8AgEAMIIENQYJKoZIhvcNAQcBMBwGCiqGSIb3DQEMAQMwDgQIjdBS

+TZF+xQCAgP5gIIECNtJIUg23ab7AXi33MKueO03S1pUkHCQk+kByNK/6f1FgEvu

XRqhniR3mdyzeMVBCrCBSx3GhZlpLcW/d6OAd3z8hbXjvw5OC5OLavemfRNtsi+R

q9LggkcWT2oCszc2nglKzHYaFnkG80vwxLwUXmROL+UK4ZlYmqp46EjuNAEo/yqQ

yEwgia3iP84wiZRfY9kBJMq9yUm+LvowO/1E9v/ycgE6IWe1CrThQzrD6Vm9LaTy

0oZqAbTbzbedZwGsuWZoedw2FtmRijkH5EbRNRpTrUUO/qQMO19v5IKtd4kUAWea

dpYrwn1kkD2aInKKsjycCFtGopXPbmrqj2cm335cESN4XePBHQuzaywHgd0WjU5O

++UM+B/5Kpx3af53E412pGAcgnPH/ZQKMa5Zkp73pcFmViLEC7Tn9eNB2iNUfX9p

rV3RNRnrEPZlD1MuYEkmBIWA5czUiDKrpyYA1fmrSsFthFMhD5fTVoDMSTBmNXPz

5B8HYW4+aDbo7N2a+BtFNcbMqYJqYwVL7xE2rL6nUedMyN2uKeZfOnLLQuYoUCg7

iYO5k7D/jQNsviyZg022Nzwy4agdPBKqok8oanQge8/pr3NeMrNDDKVyWy8ZBVBv

KGi3qaX45ejJxP8XaJxxw88+KOc1OvAMhWhAHlHqpw9d7OiAP1oCV+vRuYnD5N9a

YyLspoKy1nk+Htl71QQ4GYCRRGXMl7YsxtRrUSOAZa2+V/5h6ljUsTsib3VhO0eL

/jf+BlBxhpWw1J9L0r6sFMYvVS3AsqfqnBLJUFLxeQxYvVsV0Gpx8BonpZACQC91

DB4oV0l6whqtAQ4dJMJEk9nNnP0NYsVceKybF5NvgL3lzALw/Ezv8K7Y69FJaM35

LrT9JlGSt/BJ0oXp4wxqH4UbHikhGpSCteh7k3ZQkbE4fokVhH9lYkMXqBRXqXlI

nV9b7hR26NeJY0C7a9VyNXtzIVsP+JiBhDzc7GDafIF99fUHPVfqh15CPnTb5liZ

A6QlYw1aVvyhS8ST4I117kALKWUdl9xhe+ui0IFCEQY/mNuQ8O13nlcx+DvGtPxc

WCUG0VpP6AkE9Mkd67CghF6sFh/8FqdE1jU2Asj+iCZVU/s0ngH3hAXwMVUwOW9S

voxYParz1b0sF7vgrhLteHOZ03TEra7rh7OiOVUCOE6CACG1qV8QXDvpkZp2mGTx

5T7ob8nNF8XQWhIHjULVdKdOBuMh/4dOrHTuU5cFosR29mbzAZDDi0myuzTv37GJ

OgyiX0XXvwn5jCmAoaE0ji1fgxrWUs8yVYYHOj3IyQwzU+FydfKtlnhh8ZxHKDBo

8wPqrEAzTXT49bsxvy3cYxUp4Dd1G2ymkoTZonEi7Vir0kN7qjCCBVYGCSqGSIb3

DQEHAaCCBUcEggVDMIIFPzCCBTsGCyqGSIb3DQEMCgECoIIE7jCCBOowHAYKKoZI

hvcNAQwBAzAOBAh2oqSgVyE4cwICA/EEggTInCkEbWknH/Vojqzmn1jIPRGb7dG+

egxS5YDtk14LxnQuwACTQef2wQnKlosYbfH8dJVIvXRYB19MXroGpd5KJA8Dftqa

dWFVAcDIrzV/ZS252aita0fKOVeqjKWo7TkA9jnwDeekAcK+1R5ioIcfXPLJDSUX

gdEaza88oQ+g+34+B2o+mnTPT/PM/o1n6cifVRURn2jMASwiB/cwLn58UZibCSgL

h3CrcKamWi8AF3eJ2rkpPuK41s8SfqZ1ByNEFSgnsX5UQzJpn8FoBPBOmFnR8FTr

XNwtT7GcJJuWDSnf+On2PI2LYT6XAhNeCkfMwdnUa6N1YV2Okelmae4J21sldQlw

ATZFiuigyPMFF1X3wUfdvZTwQGC17YFTN+OIYF9/62XTiZUEJ6y0I3nRvAxpaRHS

VVyh2KA89e5Llxv+bArgA6brykRHFk5I7e7krrflPoQJ0o1oKhb8DshnxAk65v/H

xTPLq9gac81AY8rWnrTCZcO+inCan/IlOKDXnVCUfZATtAOOIQ6Mf9KwuAeyE9xu

4dUO0vF5juFU6hK8SR//apf0JF+zejq5wnEhc1o/sWVpKQkakYayJ+4Hnlx+G6Ra

bJ3ZYQv4U/kUx0Q43qvvwhx0qdZ79BUpqPTxLeBzwVG6q5ys8eZY988YcIg11NY9

+qC4cFGBsbMuWSispichDN5wEJ9C9UrdKRGsAztz0j1GTiJcXPnBH+vTeULh7Spx

GmLbJWyj3tg+QaefDPo4aaIpZCZV0BFSy41fgoBB+rZ45wNgRiDuDuHue2WY28PC

dGrAuXzQTUeEUYqN2zL2DhiYD/6/Y+/BCUS/kO0w3x0J7ityoSlyVJ+cf84FYmtB

zmPIqgjDZS/NGC0OWgUBWxzspADETmwpZDCz8MJHK99nbAcYz3AybW6307NCJTKp

gPfH6RyTrDzoijIweHUeU2pANpDjbp53UKV5/WyEvbjvy9maf1Jze60zS7EFgZ/n

ZEe+eQbSY5SGtTWCB3mMbOTFvDH0QKGbfj6EX2Z+P+RZEeU/xzMOejcBbOO7XpgV

+Uryt+NgcocTtg/5YjVkAdMeVz9A/XdGydAy7hE2FwFI1hJTl/aI4ZaAKV34xH2r

J4/VstlG8ongv9zMNaS4Xl1n3wk6W3oAUmqWdoYYyDsocIBl1he1oP588Capa7OL

NLYDl3llQXbyah1A//xJsH5M8KiB0MlJ0qSSp0U7LXmxDP3dw3kcR9XgOX835Bpi

NlOPQDfzYZyKN6sIGDcuxwQPdOg2EQZxI3W5xp+oHTM/yTuqo/5vpOIlMdwqfQ/R

HGLVyyQ0yO3oIMxiE56jSnrhjj/H/bJJAMMUBXI6pi18JCv24cTjVsXGjsf4jH7g

9uGmoecX/Sx77Sx+814aO0Qkm0WzadLagKoz1nOV1hmeSan1nFnXkE94VqIJ9YTV

qnLrY0JYjpI2ywkW4wCscjVMIxkAfhifc31v4LWUnTMO0Y+xqO89v1hKbSYkZYYs

psrxnomXJq/RqjfZBhF3f+0aTNxpvlJnGOjnlT0qX1yHBOr+bmkcTIhL7pKA+qK1

fZD8834wTLrRcFiPD7pX6/zglMEG4PUf1RoDC0+3Ud8qa2SqfyYZeFm8+9yFsFnZ

RYFkMTowIwYJKoZIhvcNAQkUMRYeFABDAEEAQwBUAEUAUwBUACAAQwBBMBMGCSqG

SIb3DQEJFTEGBAQBMDswHzAHBgUrDgMCGgQUoiKIky5oqgCxt5DnJxWNQvZ1

WecEFDabnXfA8sLdfwIXx9AexvOOS0gpAgID+w==

-END CERTIFICATE-

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] CRL implementation caching

[Mody, Darshan (Darshan)]

Hi,

We have modified our codebase to have CRL verification on the incoming 
certificates. While doing a negative testing with load of certificates I find 
that the resident memory for the module.

My query is when we have CRL verification enabled does openssl caches incoming 
certificates?

Please note that we have set SSL_CTX_set_session_cache_mode(ctx, 
SSL_SESS_CACHE_OFF);

>From the core file generated I am observing many entries of the far-end 
>certificate serial number.

Thanks in Advance

Regards
Darshan
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Visual Studio 2015 build failure

[pepone.onrez]

I trying to build openssl 1.0.2 from OpenSSL_1_0_2-stable branch and
keep getting this error


perl Configure VC-WIN32 no-asm enable-static-engine
ms\do_ms
nmake -f ms\ntdll.mak


link /nologo /subsystem:console /opt:ref /debug /dll
/out:out32dll\libeay32.dll /def:ms/LIBEAY32.def
@C:\Users\ppgut\AppData\Local\Temp\nmE41E.tmp
 Creating library out32dll\libeay32.lib and object out32dll\libeay32.exp
bss_fd.obj : error LNK2001: unresolved external symbol
OPENSSL_UplinkTable [D:\3.7\openssl\msbuild\openssl.build.targets]
bss_file.obj : error LNK2001: unresolved external symbol
OPENSSL_UplinkTable [D:\3.7\openssl\msbuild\openssl.build.targets]
b_dump.obj : error LNK2001: unresolved external symbol
OPENSSL_UplinkTable [D:\3.7\openssl\msbuild\openssl.build.targets]
out32dll\libeay32.dll : fatal error LNK1120: 1 unresolved externals
[D:\3.7\openssl\msbuild\openssl.build.targets]
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio 14.0\VC\BIN\amd64\link.EXE"' : return code '0x460'
[D:\3.7\openssl\msbuild\openssl.build.targets]
  Stop.
D:\3.7\openssl\msbuild\openssl.build.targets(20,3): error MSB3073: The
command "nmake -f ms\ntdll.mak" exited with code 2.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] mingw 64-bit build of 1.1.0e

[Matt Caswell]

On 12/03/17 07:57, sisyph...@optusnet.com.au wrote:
>> But where did it find libz ?
> 
> Heh ... this compiler ships with libz.a (x86_64-w64-mingw32/lib/libz.a).
> I don't know how long they've been doing that - probably for years.
> Remove (or rename) that file and 'make' fails because -lz can't be
> resolved.

You can specify where to find libz with the following Configure options:

  --with-zlib-include=DIR
  --with-zlib-lib=LIB

Check the INSTALL file for details.


Matt

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL handshake failure with RSA bad signature error

[Senthil Raja Velu]

Hi,
Could someone shed some light on this above mentioned RSA bad signature
issue.

Thanks,
Senthil.


On Thu, Feb 23, 2017 at 12:31 AM, Senthil Raja Velu 
wrote:

> Hi,
> I have recently updated my openssl server version from 1.0.1m to 1.0.2j.
> After updating the handshake fails with the client. The client still use
> openssl version 1.0.1e-fips.
>
> Note: With older openssl server version (1.0.1m) the handshake works with
> the same set of certificates.
>
> Here is the complete handshake message sequence from the server side with
> all debugs:
>
> TlsInfoCB HANDSHAKE_START(time:4849) sCount(0) cCount(1)
> undefined:before/accept initialization
>
> TlsInfoCB SSL_accept:before/accept initialization
>
> TlsMsgCB TLS-MSG: <<< ???  len=5
>
> TlsHexDumpCB
>  - 16 03 01 00 94.
>
> TlsMsgCB TLS-MSG: <<< TLSv1.2 Handshake len=148  ClientHello
>
> TlsHexDumpCB
>  - 01 00 00 90 03 03 58 ad-d7 b5 64 af 9e d2 38 c4   ..X...d...8.
> 0010 - 4a 8b fc 7c 3b 2f 12 64-68 70 c4 57 73 54 54 ce   J..|;/.dhp.WsTT.
> 0020 - 82 dd f2 58 c7 85 00 00-24 00 0a 00 2f 00 32 00   ...X$.../.2.
> 0030 - 33 00 35 c0 14 c0 03 c0-04 c0 05 c0 08 c0 09 c0   3.5.
> 0040 - 0a c0 0d c0 0e c0 0f c0-12 c0 13 00 ff 01 00 00   
> 0050 - 43 00 0b 00 04 03 00 01-02 00 0a 00 08 00 06 00   C...
> 0060 - 19 00 18 00 17 00 23 00-00 00 0d 00 22 00 20 06   ..#.". .
> 0070 - 01 06 02 06 03 05 01 05-02 05 03 04 01 04 02 04   
> 0080 - 03 03 01 03 02 03 03 02-01 02 02 02 03 01 01 00   
> 0090 - 0f 00 01 01   
>
> TlsExtCB TLS-EXT: client "EC point formats" (id=11) len=4
>
> TlsHexDumpCB
>  - 03 00 01 02   
>
> TlsExtCB TLS-EXT: client "elliptic curves" (id=10) len=8
>
> TlsHexDumpCB
>  - 00 06 00 19 00 18 00 17-  
>
> TlsExtCB TLS-EXT: client "session ticket" (id=35) len=0
>
> TlsExtCB TLS-EXT: client "signature algorithms" (id=13) len=34
>
> TlsHexDumpCB
>  - 00 20 06 01 06 02 06 03-05 01 05 02 05 03 04 01   . ..
> 0010 - 04 02 04 03 03 01 03 02-03 03 02 01 02 02 02 03   
> 0020 - 01 01 ..
>
> TlsExtCB TLS-EXT: client "heartbeat" (id=15) len=1
>
> TlsHexDumpCB
>  - 01.
>
> TlsInfoCB SSL_accept:SSLv3 read client hello A
>
> TlsMsgCB TLS-MSG: >>> ???  len=5
>
> TlsHexDumpCB
>  - 16 03 03 00 3a:
>
> TlsMsgCB TLS-MSG: >>> TLSv1.2 Handshake len=58  ServerHello
>
> TlsHexDumpCB
>  - 02 00 00 36 03 03 b6 97-ce 9a 96 74 98 52 c0 4a   ...6...t.R.J
> 0010 - c4 2e f4 20 1f 47 c0 b3-2e e4 8c ed 79 9e 22 e1   ... .G..y.".
> 0020 - 57 f9 1f 56 c4 b5 00 00-0a 00 00 0e ff 01 00 01   W..V
> 0030 - 00 00 23 00 00 00 0f 00-01 01 ..#...
>
> TlsInfoCB SSL_accept:SSLv3 write server hello A
>
> TlsMsgCB TLS-MSG: >>> ???  len=5
>
> TlsHexDumpCB
>  - 16 03 03 04 f1.
>
> TlsMsgCB TLS-MSG: >>> TLSv1.2 Handshake len=1265  Certificate
>
> TlsHexDumpCB
>  - 0b 00 04 ed 00 04 ea 00-02 15 30 82 02 11 30 82   ..0...0.
> 0010 - 01 7a 02 09 00 aa f8 6d-8b 4d d8 0f f0 30 0d 06   .z.m.M...0..
> 0020 - 09 2a 86 48 86 f7 0d 01-01 05 05 00 30 4e 31 0b   .*.H0N1.
> 0030 - 30 09 06 03 55 04 06 13-02 55 53 31 13 30 11 06   0...UUS1.0..
> 0040 - 03 55 04 08 13 0a 43 61-6c 69 66 6f 72 6e 69 61   .UCalifornia
> 0050 - 31 10 30 0e 06 03 55 04-07 13 07 53 61 6e 4a 6f   1.0...USanJo
> 0060 - 73 65 31 18 30 16 06 03-55 04 03 13 0f 77 77 77   se1.0...Uwww
> 0070 - 2e 6e 75 61 67 65 43 41-2e 63 6f 6d 30 1e 17 0d   .nuageCA.com0...
> 0080 - 31 34 30 39 30 34 30 39-35 37 35 30 5a 17 0d 32   140904095750Z..2
> 0090 - 34 30 39 30 31 30 39 35-37 35 30 5a 30 4c 31 0b   40901095750Z0L1.
> 00a0 - 30 09 06 03 55 04 06 13-02 55 53 31 13 30 11 06   0...UUS1.0..
> 00b0 - 03 55 04 08 13 0a 43 61-6c 69 66 6f 72 6e 69 61   .UCalifornia
> 00c0 - 31 10 30 0e 06 03 55 04-07 13 07 53 61 6e 4a 6f   1.0...USanJo
> 00d0 - 73 65 31 16 30 14 06 03-55 04 03 13 0d 77 77 77   se1.0...Uwww
> 00e0 - 2e 6e 75 61 67 65 2e 63-6f 6d 30 81 9f 30 0d 06   .nuage.com0..0..
> 00f0 - 09 2a 86 48 86 f7 0d 01-01 01 05 00 03 81 8d 00   .*.H
> 0100 - 30 81 89 02 81 81 00 d1-2f 3b 18 80 af 87 aa f3   0.../;..
> 0110 - dd 62 5f 96 d6 69 ba 28-cf f6 56 7f c8 56 62 de   .b_..i.(..V..Vb.
> 0120 - 7a 9d fc 6d 26 17 df 0d-5f 09 15 5e 24 68 04 37   z..m&..._..^$h.7
> 0130 - e0 02 47 e3 18 64 5c 2e-0a 2e 89 57 f9 54 b0 97   ..G..d\W.T..
> 0140 - 93 24 06 8b 22 55 54 68-89 ea 8d 1d 97 b0 d2 8b   .$.."UTh
> 0150 - 5b 34 19 ba 41 c0 da ca-49 82 d4 76 a3 de 5f fc   [4..A...I..v.._.
> 0160 - cf fa 6b 22 6c 8c c9 af-c2 e4 2b 08 75 cf 3d 5a