Re: odd error for ECDSA key in REQ.

[Frank Migge]

Hi Dirk-Willem,

Something is wrong with your EC key. The error mentions that it can't
get the curve points from the key data. How did you generate the key?

If it helps, here is a working CSR example, using a prime256v1 key for
comparison:

-BEGIN CERTIFICATE REQUEST-
MIIBDjCBtAIBADArMQswCQYDVQQGEwJKUDEcMBoGA1UEAwwTdGVzdCBmb3IgcHJp
bWUyNTZ2MTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABOMQV0Vep+9Xnje6bKNy
+8blwKEscr5LoUQCuwqaUT4HyPgXFE9E0r1PiWbC6bGkS26MuguOBp52X9H9z+NS
zM6gJzAlBgkqhkiG9w0BCQ4xGDAWMBQGA1UdEQQNMAuCCWZtNGRkLmNvbTAKBggq
hkjOPQQDAgNJADBGAiEA5uYlfkpRsJhBk+WwippCjupEpaCNaHwNyNqbj8qrR80C
IQDCoJtaWhFGxbaAB2+o3gm87ZHJSDSjfrD2lEhlkbEXHQ==
-END CERTIFICATE REQUEST-


$ openssl req -inform PEM -noout -pubkey -in test.csr
-BEGIN PUBLIC KEY-
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE4xBXRV6n71eeN7pso3L7xuXAoSxy
vkuhRAK7CppRPgfI+BcUT0TSvU+JZsLpsaRLboy6C44GnnZf0f3P41LMzg==
-END PUBLIC KEY-


On Fri, 2020-08-07 at 19:07 +0200, Dirk-Willem van Gulik wrote:
> Below CSR gives me an odd error with the standard openssl REQ
> command:
> 
>   openssl req -inform DER -noout -pubkey
> 
>   Error getting public key
> 
>   140673482679616:error:10067066:elliptic curve
> routines:ec_GFp_simple_oct2point:invalid
> encoding:../crypto/ec/ecp_oct.c:312:
>   140673482679616:error:10098010:elliptic curve
> routines:o2i_ECPublicKey:EC lib:../crypto/ec/ec_asn1.c:1175:
>   140673482679616:error:100D708E:elliptic curve
> routines:eckey_pub_decode:decode error:../crypto/ec/ec_ameth.c:157:
>   140673482679616:error:0B09407D:x509 certificate
> routines:x509_pubkey_decode:public key decode
> error:../crypto/x509/x_pubkey.c:125:
> 
> Even though the ASN1 of the public key looks correct to me:
> 
> SEQUENCE (2 elem)
>   SEQUENCE (2 elem)
> OBJECT IDENTIFIER 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62
> public key type)
> OBJECT IDENTIFIER 1.2.840.10045.3.1.7 prime256v1 (ANSI X9.62
> named elliptic curve)
>   BIT STRING (536 bit)
> 01000101011110010011001110011100011010001010010110100
> 0…
> OCTET STRING (65 byte)
> 0439339C68A5A333143592C0A36D053F31D3AF6ED18FB54F4747B9DFC6DB6ABC71556
> 1…
> 
> What would be a good way to further debug this ?
> 
> With kind regards,
> 
> Dw
> 
> -BEGIN CERTIFICATE REQUEST-
> MIIBPzCB5QIBADCBgDELMAkGA1UEAxMCQ04xCjAIBgNVBAUTATExCjAIBgNVBAYT
> AUMxCjAIBgNVBAcTAUwxCjAIBgNVBAgTAVMxCjAIBgNVBAoTAU8xCzAJBgNVBAsT
> Ak9VMQowCAYDVQQMEwFUMQowCAYDVQQNEwFEMRAwDgYJKoZIhvcNAQkBEwFFMFsw
> EwYHKoZIzj0CAQYIKoZIzj0DAQcDRAAEQQQ5M5xopaMzFDWSwKNtBT8x069u0Y+1
> T0dHud/G22q8cVVh8sVcpLUortLxxesEXCddpx/EeuxP+MN/RymHTMrjoAAwCgYI
> KoZIzj0EAwIDSQAwRgIhAO+K+TFCdYxQg7aT+B3wIVa6CCYxM/mL4/WHSrwXujJy
> AiEA7UsbQT/YRKaFDPn/U9jdrJaUmKsqKJvGwN7YVaMGdeo=
> -END CERTIFICATE REQUEST-


-- 
Frank Migge
http://fm4dd.com | pub...@frank4dd.com

Re: [openssl-users] Combining certificate and key in PEM format into a P12 file without knowing the key password?

[Frank Migge]

Hi Toby,

>> the question remains: Is there a way to reuse an already-encrypted privkey?

I'd say yes it *could* work, but not with OpenSSL API functions. You'd
have to roll your own code for the PKCS12 creation.

OpenSSL's PKCS12_create() function expects an unencrypted EVP_PKEY
object.  But, internally, that key is turned into a encrypted PKCS8
structure, as expected by the PKCS8ShroudedKeyBag type defined in RFC-7292.

Thats why I think it may be possible to experiment and modify code such
as in crypto/pkcs12/p12_crt.c, trying to pass-through that already
encrypted PKCS8 key "as-is" straight into the pkcs8ShroudedKeyBag
object. If your key is a file in PEM format, you'd need to get that into
an internal structure first (more coding), I don't think there is a
simple API import (without decryption).

If you manage to successfully built that PKCS12, you'd run into trouble
for decoding, which probably fails for all known software. They all
expect to be able to read the private key, when in your case it needs
saving to a file somewhere for further handling, or for entering that
second key-specific password.  You'd again have to code your own PKCS12
unpack program, just for this specific use case.

I may be wrong but to me it looks doable, just a *lot* of work.

Frank
> Tobias Dussa (SCC) 
> Tuesday, February 20, 2018 9:15 PM
> Hi,
>
> On Tue, Feb 20, 2018 at 12:23:14PM +0100, Jakob Bohm wrote:
>>> Googling does not reveal much useful information, unfortunately, and so far 
>>> we
>>> have been unsuccessfully diving into PKCS12/8/5 specs.  I don't really see a
>>> reason why it should not be possible, but of course that doesn't mean it 
>>> is. :)
>> In the commonly accepted variants of PKCS#12, private key and all the
>> certificates are encrypted with the same password.  PKCS#12 with
>> different password for private key and certificates is not widely
>> supported.
>
> I see.
>
>> In the concatenated PEM format, only the private key is encrypted, but
>> not the certificates.
>
> Yep.
>
>> So to convert from concatenated PEM format to PKCS#12, even if the
>> encrypted private key could be kept without decrypting the private
>> key, the password for the private key is still needed to encrypt
>> the certificates with the same password.
>
> ... iff you need to retain wide-spread compatibility.  So if that is not
> necessary, the question remains: Is there a way to reuse an already-encrypted
> privkey?
>
> THX & Cheers,
> Toby.
> Jakob Bohm 
> Tuesday, February 20, 2018 8:23 PM
>
> In the commonly accepted variants of PKCS#12, private key and all the
> certificates are encrypted with the same password.  PKCS#12 with
> different password for private key and certificates is not widely
> supported.
>
> In the concatenated PEM format, only the private key is encrypted, but
> not the certificates.
>
> So to convert from concatenated PEM format to PKCS#12, even if the
> encrypted private key could be kept without decrypting the private
> key, the password for the private key is still needed to encrypt
> the certificates with the same password.
>
>
> Enjoy
>
> Jakob
> Tobias Dussa (SCC) 
> Tuesday, February 20, 2018 7:04 PM
> Hi,
>
> I was wondering whether it was possible somehow to take a certificate
> and an
> enciphered private key, both in .pem format, and combine them into a
> PKCS12
> structure without knowing the key passphrase?
>
> Googling does not reveal much useful information, unfortunately, and
> so far we
> have been unsuccessfully diving into PKCS12/8/5 specs. I don't really
> see a
> reason why it should not be possible, but of course that doesn't mean
> it is. :)
>
> THX & Cheers,
> Toby.

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

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

[Frank Migge]

I got it wrong. The failing cert from your log is actually the
intermediate, which has five extensions:

>> Object 00: X509v3 Subject Key Identifier:
58:A4:EB:D9:DD:CE:A2:99:72:3B:E1:20:19:1D:40:C1:F9:D5:C2:28
>> Object 01: X509v3 Authority Key Identifier:
keyid:E2:E9:20:42:29:83:C4:77:8C:87:AB:FA:4B:A1:A9:C4:CE:00:BD:39
>> Object 02: X509v3 Basic Constraints: CA:TRUE, pathlen:0
>> Object 03: X509v3 Key Usage: Digital Signature, Certificate Sign, CRL
Sign
>> Object 04: X509v3 Extended Key Usage: TLS Web Server Authentication

This is were I would check first.

I am not fully sure, but believe that Extended Key Usage should *not* be
there.

Frank

> Frank Migge <mailto:f...@frank4dd.com>
> Saturday, January 20, 2018 11:29 AM
> Hi Robert,
>
>>> error 26 : unsupported certificate purpose
>
> It seems the cert gets declined because of a problem with cert
> extensions. "keyUsage" or "extendedKeyUsage" are typical candidates. In
> your case, the leaf certificate "CAPF-91d43ef6" has two extensions:
>
> Object 00: X509v3 Key Usage
>   Digital Signature, Key Encipherment
>
> Object 01: X509v3 Extended Key Usage
>   TLS Web Server Authentication, TLS Web Client Authentication, IPSec End 
> System
>
> I would check if an extension is now missing/newly required, or no
> longer recognized. Try check for differences in the openssl.cnf and
> freeradius config files between the old Debian system and the new one.
>
> Some EAP TLS guides (incl. Cisco) also list extensions "nonRepudiation" and 
> "dataEncipherment", but this is just a guess since you mentioned it works on 
> the old system.
>
>>> I have some problems with new Cisco CAPF certs
>
> What is the authenticating device? Cisco IP phone?
>
> Cheers,
> Frank
> Gladewitz, Robert via openssl-users <mailto:openssl-users@openssl.org>
> Friday, January 19, 2018 11:12 PM
>
> Dear OpenSSL Team,
>
>  
>
> I have some problems with new Cisco CAPF certs and freeradius tls
> authentification. The point is, that freeradius users see the problem
> on openssl implemtiation.
>
>  
>
> 
>
> (69) eap_tls: Continuing EAP-TLS
>
> (69) eap_tls: Peer indicated complete TLS record size will be 1432 bytes
>
> (69) eap_tls: Got complete TLS record (1432 bytes)
>
> (69) eap_tls: [eaptls verify] = length included
>
> (69) eap_tls: TLS_accept: SSLv3/TLS write server done
>
> (69) eap_tls: <<< recv TLS 1.0 Handshake [length 03c2], Certificate
>
> (69) eap_tls: Creating attributes from certificate OIDs
>
> (69) eap_tls:   TLS-Cert-Serial := "1009"
>
> (69) eap_tls:   TLS-Cert-Expiration := "38025719Z"
>
> (69) eap_tls:   TLS-Cert-Subject := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ
> Deutsches Biomasseforschungszentrum gGmbH/OU=IT/CN=CAPF-91d43ef6"
>
> (69) eap_tls:   TLS-Cert-Issuer := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ
> Deutsches Biomasseforschungszentrum gemeinnuetzige GmbH/OU=IT/CN=DBFZ
> CA INTERN ROOT/emailAddress=supp...@dbfz.de
> <mailto:ROOT/emailAddress=supp...@dbfz.de>"
>
> (69) eap_tls:   TLS-Cert-Common-Name := "CAPF-91d43ef6"
>
> (69) eap_tls:   ERROR: SSL says error 26 : unsupported certificate purpose
>
> (69) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal
> unsupported_certificate
>
> (69) eap_tls: ERROR: TLS Alert write:fatal:unsupported certificate
>
> tls: TLS_accept: Error in error
>
> (69) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read):
> error:1417C086:SSL routines:tls_process_client_certificate:certificate
> verify failed
>
> (69) eap_tls: ERROR: System call (I/O) error (-1)
>
> (69) eap_tls: ERROR: TLS receive handshake failed during operation
>
> (69) eap_tls: ERROR: [eaptls process] = fail 
>
> 
>
>  
>
> This means, that the check of ca certificate is failed. So, bu I do
> not see, why. If i check the certificate by command openssl –verify,
> all sems to be right.
>
> # openssl verify -verbose -CAfile
> /etc/freeradius/3.0/certs.8021x.ciscophone/cacert.capf.pem
> SEP64A0E714844E-L1.pem
>
> # SEP64A0E714844E-L1.pem: OK
>
>  
>
>  
>
> The openssl version is Debian based 1.1.0g-2. But the same error is
> happening on 1.1.0f also.
>
>  
>
> Older freeradius version 2 on Debian 8/openssl 1.0.1t-1+deb8u7 working
> fine without this problem (by using the same certificates)
>
>  
>
> The ca certificate are signed by an intern ca. Can anyone see the error??
>
>  
>
> Robert
>
>  
>
>  
>
>  
>

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

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

[Frank Migge]

Hi Robert,

>> error 26 : unsupported certificate purpose

It seems the cert gets declined because of a problem with cert
extensions. "keyUsage" or "extendedKeyUsage" are typical candidates. In
your case, the leaf certificate "CAPF-91d43ef6" has two extensions:

Object 00: X509v3 Key Usage
  Digital Signature, Key Encipherment

Object 01: X509v3 Extended Key Usage
  TLS Web Server Authentication, TLS Web Client Authentication, IPSec End System

I would check if an extension is now missing/newly required, or no
longer recognized. Try check for differences in the openssl.cnf and
freeradius config files between the old Debian system and the new one.

Some EAP TLS guides (incl. Cisco) also list extensions "nonRepudiation" and 
"dataEncipherment", but this is just a guess since you mentioned it works on 
the old system.

>> I have some problems with new Cisco CAPF certs

What is the authenticating device? Cisco IP phone?

Cheers,
Frank

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

Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates

[Frank Migge]

This is an interesting statement.

>> should use the GeneralizedTime value 1231235959Z (10) in the
notAfter field ...
>> Solutions verifying a DevID are expected to accept this value
indefinitely

Isn't using that large a time value in certificates problematic? Not all
systems can handle it today. At best, they may gracefully decline it as
invalid. Windows up to version 10 is unable to display it, and fails to
work with such a cert.

Even closer into the future, 20 years from now, I am not sure how far
the industry came in dealing with the upcoming year 2038 problem on
32bit systems. It is indirectly related to OpenSSL when system time is
used, converted to or from. Particularly in IOT/ICS industry situations
with scaled down CPUs, long device lifespans and support requirements,
functional validation with future time settings would definitely be a
good idea on the test plan.

Frank
> Robert Moskowitz 
> Wednesday, September 13, 2017 12:57 AM
> IEEE 802.1ARce (latest draft addendum) specifies:
>
> 8.7 validity
>
> The time period over which the DevID issuer expects the device to be used.
>
> All times are stated in the Universal Coordinated Time (UTC) time
> zone. Times up to and including
> 23:59:59 December 31, 2049 UTC are encoded as UTCTime as
> YYMMDDHHmmssZ. Times later than
> 23:59:59 December 31, 2049 UTC are encoded as GeneralizedTime as
> MMDDHHmmssZ.
>
> The time the DevID is created is encoded in the notBefore field of
> DevID certificates. Each DevID chain
> certificate has a notBefore value that encodes a time that is the same
> as or prior to that of any DevID
> certificate that relies on the chain for certificate validation.
>
> The latest time a DevID is expected to be used is encoded in the
> notAfter field of the DevID certificate.
> Each DevID chain certificate has a notBefore value that encodes a time
> that is the same as or later than that of any DevID certificate that
> relies on the chain for certificate validation.
>
> Devices possessing an IDevID are expected to operate indefinitely into
> the future and should use the
> GeneralizedTime value 1231235959Z (10) in the notAfter field of
> IDevID certificates. Solutions
> verifying a DevID are expected to accept this value indefinitely.
> Values in notAfter fields are treated as
> specified in RFC 5280.
>
> Footnote: (10)
> This value corresponds to one second before the year 10 000; note the
> creation of an opportunity for the Y10K bug fix industry.
>
> =
>
> It is really rare to find humor in IEEE specifications!
>
> Bob
>
> On 09/12/2017 11:39 AM, Alejandro Pulido wrote:
>
> Robert Moskowitz 
> Tuesday, September 12, 2017 11:30 PM
> Depends on the question
>
> 'Infinite' duration is used in IEEE 802.1AR Device Identities.  The
> concept is the vendor installs the certificate in read-only memory. 
> It is expected to be good for the life of the device.
>
> On 09/11/2017 05:32 AM, Alejandro Pulido wrote:
>
> Alejandro Pulido 
> Monday, September 11, 2017 6:32 PM
> Dear team of OpenSSL,
>  
> First of all, congratulations for your invaluable work!
>  
> I have a question regarding the issue of certificates X.509 with
> infinite duration and I don't know where to submit it.
>  
> Please, could you help me?
>  
> Thank you very much and kind regards
>
>
>
> */Alejandro J Pulido Duque/*
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] RSA Key generation time

[Frank Migge]

Hi Mithun,

>> I have a embedded board P1010 RDB  running openssl on VXWORKS 5.4 .
>> I am generating RSA 2048 and 3072 bit key pairs.
>> I am providing entropy to openssl by using RAND_seed from a HW RNG.

>> My average generation time for RSA 2048 key pair is 2 Minutes and 
 3072 is 8 minutes.


I noticed embedded board key generation times vary by OS and OpenSSL 
version after converting a Altera Atlas FPGA SoC HPS from original 2013 
Yocto Linux to latest Ubuntu. Under the old Yocto, key generation 
occasionally took up to 2 minutes. Same board under Ubuntu 16.04, 2048 
RSA keys take consistently 2-5 seconds, while 3072 keys need around 8-16 
seconds. Even running the system single core, the numbers don't change 
(on a low utilized system, using OS built-in /dev/urandom).


While I am on a different CPU and OS (32bit ARM v7  900Mhz dual core, 
1GB 400Mhz RAM), your e500 PowerPC can't be to far behind. Your numbers 
seem to be off by a magnitude. You mentioned using a external HW RNG, 
could that be it?


Cheers,
Frank

Jakob Bohm 
Wednesday, January 25, 2017 1:10 AM
I'm afraid you will have to look at the OpenSSL source code, I haven't
paid much attention to that CPU recently.




Enjoy

Jakob
Mithun P 
Monday, January 23, 2017 4:09 PM
Hi Jakob,

Can you please give me some reference/example of bignum optimization 
which I can check on powerpc architectures.

Is this any specific instruction set addition? or something more generic?

Thanks & Regards
Mithun


Jakob Bohm 
Wednesday, January 18, 2017 1:08 AM

I believe this is a CPU intensive operation (if VxWorks can do
this, try observing the CPU load during).

Potential improvements:

1. Check if the CPU specific bignum optimizations for your CPU
  variant have been enabled via the libcrypto CPU detection code
  (for example, there are optimizations for different ARM cortex
  variants).
2. Faster CPU (expensive obviously).
3. Do the generation in the background before the keypair is
  needed, at a time when the extra CPU load is less of a problem.


Enjoy

Jakob
Mithun P 
Tuesday, January 17, 2017 3:44 PM
Hi

I have a embedded board P1010 RDB  running openssl on VXWORKS 5.4 .
I am generating RSA 2048 and 3072 bit key pairs.
I am providing entropy to openssl by using RAND_seed from a HW RNG.

My average generation time for RSA 2048 key pair is 2 Minutes and 
 3072 is 8 minutes.

Is there a way to reduce the generation time?

Regards
Mithun

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

Re: [openssl-users] Missing documentation

[Frank Migge]

Hi Joachim,

>> It seems like the documentation for SSL_set_tlsext_host_name is gone.
>> Does anyone know where I can find the documentation? I am interested 
in the return values right now.


If I got it right:

1) ssl/tls1.h (line 334ff): #  define SSL_set_tlsext_host_name(s,name) \
334 
SSL_ctrl(s,SSL_CTRL_SET_TLSEXT_HOSTNAME,TLSEXT_NAMETYPE_host_name,(char 
*)name)


2) https://www.openssl.org/docs/manmaster/man3/SSL_ctrl.html:
The return values of the SSL*_ctrl() functions depend on the command 
supplied via the *cmd* parameter.


3) ssl/s3_lib.c (line 3311 ff): case SSL_CTRL_SET_TLSEXT_HOSTNAME:
returns 1 on success, and 0 on failure which also writes the cause to 
the SSL error handler.


Best wishes
Frank
 

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

Re: [openssl-users] Certificate Chain Verify Error

[Frank Migge]

Hi Nicholas,

Not calling OpenSSL_add_all_algorithms();  at the beginning could cause it?

Cheers,
Frank


Nicholas Mainardi 
Monday, February 01, 2016 8:57 PM
I wrote this small program which takes as input X509 certificates, 
base64-encoded, parse them and build a certificate chain, which is 
eventually verified by |x509_Verify_cert()|. The last certificate is 
added to the trusted store if it's self-signed, in order to avoid 
OpenSSL policy about self.signed certificates, as it's recommended in 
this post 
. The 
code is at this pastebin link .


However, when I run this with a correct certificate chain (Facebook 
one, already tested with other libraries), I got error 7, certificate 
signature validation, at depth 1. The certificate chain is composed by 
server certificate, CA certificate and a self-signed root certificate, 
which is also in the trusted system store. Hence, it seems that the 
public key of the self-signed root certificate is not correctly used 
to verify the signature on the CA certificate. Moreover, I compile the 
same source but linking boringSSL crypto library instead of OpenSSL 
one, and everything works perfectly. Hence, my hyphotesis is that this 
is an OpenSSL issue found by Google and fixed in BoringSSL, but it has 
not been fixed in OpenSSL yet. So, I would like to know if I'm missing 
some steps in order to properly use |x509_verify_cert()| method, or my 
hyphotesis about BoringSSL fixing could be appropriate.


Thank You,

Nicholas

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


--
Sent with Postbox 
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] d2i_RSAPrivateKey not working on a private key

[Frank Migge]

Hi David,

I didn't spot the error in your code. But since d2i_RSAPrivateKey() 
fails on the DER data, how about a workaround? If your remaining code 
works fine, you could extract the RSA key from the EVP_PKEY object 
(which you are getting with d2i_PrivateKey), e.g.


   RSA *rsakey;
   rsakey = EVP_PKEY_get1_RSA(privkey);  // this reads EVP_PKEY, best 
to test before to ensure it is RSA


   if (RSA_check_key(rsakey)) { printf("RSA key is valid.\n"); }
   else { printf("Error validating RSA key.\n"); }

   RSA_print_fp(stdout, rsakey, 3);
   ...

Alternatively, building a test case around d2i_RSAPrivateKey() to see if 
the DER format is valid, e.g. converting the PEM key into DER using the 
OpenSSL commandline, and binary-compare with the programs DER data.


openssl rsa -inform PEM -in test-key.pem -outform DER -out key.bin

Best Wishes,
Frank

David Lobron 
Monday, October 12, 2015 11:34 PM

Thanks very much, Frank. My code reads the PEM file, base64-decodes 
it, and passes the resulting DER value to d2i_RSAPrivateKey. I 
verified that I can extract the private key with d2i_PrivateKey from 
the DER formatted data, and I can call SSL_CTX_use_PrivateKey with it 
on my SSL context without a problem. It's only when I call 
d2i_RSAPrivateKey I encounter a problem. I have included the code 
below, with annotations (it's in Objective-C).


I've got custom classes for X509Certificate and X509PrivateKey. I use 
them like this:


X509Certificate *cert = [X509Certificate 
certificateWithPemEncodedFile:certFile];
X509PrivateKey *privKey = [X509PrivateKey 
privateKeyWithPemEncodedFile:keyFile];

[cert validateWithPrivateKey:privKey];
[privKey validate];

That last call to [privKey validate] is where things fail currently. 
The validateWithPrivateKey method works fine, and it looks like this:


- (void)validateWithPrivateKey:(X509PrivateKey *)key
{
SSL_CTX *sslContext;

[self validate];
sslContext = SSL_CTX_new(TLSv1_server_method());
NS_DURING {
NSData *d = [key der];
const unsigned char *p = (const unsigned char *)[d bytes];
EVP_PKEY *pkey = d2i_PrivateKey(EVP_PKEY_RSA, NULL, , [d length]);
if (!sslContext)
[NSException raise:X509CertificateExcInternalError 
format:@"SSL_CTX_new failed: %@", sslErrorString()];

if (SSL_CTX_use_certificate(sslContext, _x) != 1)
[NSException raise:X509CertificateExcInvalidCertificate 
format:@"SSL_CTX_use_certificate failed: %@", sslErrorString()];

if (SSL_CTX_use_PrivateKey(sslContext, pkey) != 1)
[NSException raise:X509CertificateExcInvalidPrivateKey 
format:@"SSL_CTX_use_PrivateKey_ASN1 failed: %@", sslErrorString()];

SSL_CTX_free(sslContext);
} NS_HANDLER {
if (sslContext)
SSL_CTX_free(sslContext);
[localException raise];
} NS_ENDHANDLER
}

(That initial call to "self validate" simply validates the cert 
object's SSL_CTX).


I initialize my private key object as follows:

- (id)initWithPemEncodedFile:(NSString *)path
{
NSData *d = nil;
NS_DURING {
NSString *s;
NSArray *inputLines;

// read the file
s = [NSString stringWithContentsOfFile:path];
if (s == nil || [s length] == 0)
[NSException raise:X509CertificateExcParameterError format:@"File %@ 
is empty or cannot be read", path];

inputLines = [s componentsSeparatedByString:@"\n"];
d = [X509Certificate decodePemFragmentFromLines:inputLines 
withBoundaryPhrases:[NSArray arrayWithObjects:@"PRIVATE KEY", @"RSA 
PRIVATE KEY", nil]];

} NS_HANDLER {
[self release];
[localException raise];
} NS_ENDHANDLER
return [self initWithDer:d];

}

The decodePemFragmentFromLines method looks like this:

// Extract part of a PEM-encoded message, base64-decode it, and return 
an NSData object
+ (NSData *)decodePemFragmentFromLines:(NSArray *)inputLines 
withBoundaryPhrases:(NSArray *)boundaryPhrases

{
NSEnumerator *e = [inputLines objectEnumerator];
NSMutableString *b64 = [NSMutableString string];
NSString *s;
NSString *boundaryPhrase = nil;
NSString *startBoundary = nil;
NSString *endBoundary = nil;

while ((s = [e nextObject]) != nil) {
NSEnumerator *e = [boundaryPhrases objectEnumerator];
while ((boundaryPhrase = [e nextObject]) != nil) {
startBoundary = [NSString stringWithFormat:@"-BEGIN %@-", 
boundaryPhrase];

if ([s isEqualToString:startBoundary]) {
endBoundary = [NSString stringWithFormat:@"-END %@-", 
boundaryPhrase];

break;
}
}
if (endBoundary != nil)
break;
}
if (s == nil)
[NSException raise:X509CertificateExcParameterError format:@"Start 
boundary \"%@\" not found", startBoundary];

while ((s = [e nextObject]) != nil) {
if ([s isEqualToString:endBoundary])
break;
[b64 appendString:s];
}
if (s == nil)
[NSException raise:X509CertificateExcParameterError format:@"End 
boundary \"%@\" not found", endBoundary];

return base64Decode(b64);
}

The initWithDer method is simply:

- (id)initWithDer:(NSData *)der
{
if ((self = [super init]) != nil) {
_der = [der copy];
}
return self;
}

All of the above works as expected, but when I call d2i_RSAPrivateKey 
on the _der object, it fails. Here is the 

Re: [openssl-users] d2i_RSAPrivateKey not working on a private key

[Frank Migge]

Hi David,

Your attached sample certificate and private key (1024 bit RSA) works fine.
I am reading it with PEM_read_PrivateKey( fp, , NULL, NULL), and also
PEM_read_bio_PrivateKey(pkeybio, NULL, 0, NULL) works.

If you could post the code or code fragment that creates the problem?
d2i_RSAPrivateKey() is not reading PEM, just making sure...

Best wishes,
Frank Migge



David Lobron <mailto:dlob...@akamai.com>
Saturday, October 10, 2015 12:33 AM
Hello openssl people,

I am trying to read a private key of a certificate into memory using 
d2i_RSAPrivateKey. I'm able to read the certificate without a problem, 
but when I pass the private key to d2i_RSAPrivateKey, it fails to 
parse. I do not see an error message or errno being set - 
d2i_RSAPrivateKey simply returns NULL. I've generated a self-signed 
cert which reproduces the problem, and I've attached it to this 
message (this is a throwaway cert, not in use for anything, so I'm 
knowingly sending the private key). The command I used to generate 
this cert and its key was:


openssl req -x509 -newkey rsa:1024 -keyout key.pem -out cert.pem -days 
36500 -nodes -outform PEM


I have another cert where the private key *is* parseable by 
d2i_RSAPrivateKey. I printed out both certs from the command line, and 
compared them. They appear almost identical. The only difference I see 
is that when I print the attached unparseable cert, the Signature 
Algorithm section has 8 lines of hex. In the parseable cert, I see 15 
lines of hex. Both certs use sha1WithRSAEncryption as the algorithm, 
with 1024 bits.


Can anyone help me understand why the private key in the attached cert 
is not readable by d2i_RSAPrivateKey? I'm running these tests on a 
Mac, but the same thing happens on Ubuntu Linux.


Thank you,

David

Printout of the attached cert, which fails to parse with 
d2i_RSAPrivateKey:


MacBook-Air:self_signed dlobron$ openssl x509 -in cert.1024.combined 
-text -noout

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 17702003413458844255 (0xf5aa2650b7f77a5f)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=Massachusetts, L=Cambridge, O=Akamai Technologies, 
OU=KMI, 
CN=akamai.normandy_authority.client_gateway_ca.1/emailAddress=dlob...@akamai.com

Validity
Not Before: Oct 8 15:47:30 2015 GMT
Not After : Jan 16 15:47:30 2016 GMT
Subject: C=US, ST=Massachusetts, L=Cambridge, O=Akamai Technologies, 
OU=KMI, 
CN=akamai.normandy_authority.client_gateway_ca.1/emailAddress=dlob...@akamai.com

Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:c2:33:df:d8:cb:c9:6e:a4:98:f0:b7:b1:06:51:
77:f8:6c:36:4b:f3:ab:fc:09:ab:98:13:d5:0a:03:
63:31:c4:ce:6f:02:12:b5:c4:4c:83:17:39:c2:b8:
27:89:a5:80:56:36:72:19:8b:9a:dd:e5:e2:22:60:
53:96:f9:4d:c0:f1:c6:06:5f:1b:95:de:b7:8e:d2:
ef:e8:ff:84:81:73:45:c9:a5:52:6d:af:8e:6a:16:
bf:23:97:66:5e:d8:1f:0e:e9:1b:d3:03:e3:cd:4c:
02:2f:68:f0:a5:70:a3:90:f5:19:8d:f5:6b:d1:87:
e7:82:39:f9:09:1b:ee:56:f9
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
2F:D9:17:38:F0:9E:03:2C:57:E5:FF:20:24:BC:F1:AA:2C:35:AB:D5
X509v3 Authority Key Identifier:
keyid:2F:D9:17:38:F0:9E:03:2C:57:E5:FF:20:24:BC:F1:AA:2C:35:AB:D5

X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
5d:5c:c0:10:c3:60:10:c5:d4:30:cf:90:41:32:d9:73:1f:03:
66:a5:3b:ca:e2:99:2f:89:10:0e:4d:d6:b3:1d:97:ae:0a:54:
46:0b:a8:51:02:97:c6:41:32:16:db:7c:77:28:e8:df:73:70:
a0:01:73:b6:84:90:b5:a8:b7:54:53:7d:a9:cd:81:33:35:6d:
58:5e:ba:e2:7d:34:7a:32:c9:fd:4f:07:18:75:a7:53:3d:61:
1b:98:7a:e6:92:5b:74:39:e1:ab:b2:6a:51:4a:56:c5:99:1e:
d7:7a:7a:b6:32:e8:ca:f2:33:bc:3f:d5:3c:3f:87:2a:9f:ab:
37:c8


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


--
Sent with Postbox <http://www.getpostbox.com>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: multi-byte subject DN display

[Frank Migge]

Hi Bin,

# openssl x509 -in test.pem -noout -text -nameopt oneline,show_type

Subject: C = PRINTABLESTRING:US, ST = PRINTABLESTRING:California, O = 
T61STRING:\C3\A6\C2\B7\C2\84\C3\A5\C2\8D\C2\9A\C3\A7\C2\BD\C2\91\C3\A7\C2\BB\C2\9C,
 OU = PRINTABLESTRING:QA, CN = 
T61STRING:www.d8t.net-\C3\A4\C2\B8\C2\AD\C3\A6\C2\96\C2\87, emailAddress = 
IA5STRING:w...@qa.juniper.net

Your cert subject is multi-byte, but using TeletexString (T61String) encoding 
instead of UTF8. OpenSSL commandline handles multi-byte if it is UTF-8 encoded. 
Not all certificate tools, especially those web-based, can handle multibyte 
encodings other then UTF8.

For a exemplary multi-byte UTF-8 demo-cert using Japanese Katakana/Kanji, 
please see http://www.frank4dd.com/sw/webcert/export/0E13.pem.
You can also use a online cert validator, e.g. 
http://www.frank4dd.com/sw/webcert/cgi-bin/certvalidate.cgi to check for UTF-8 
output.

Hope this helps in the right direction,
Frank

From: Bin Lu 
Sent: Thursday, September 12, 2013 9:44 AM
To: openssl-users@openssl.org 
Subject: FW: multi-byte subject DN display

Re-post … as nobody responded.

 

If I use “–nameopt utf8” option, the output of the subject is empty even for 
ascii string subject DN. This does not seem to match what is said in the man 
page. A bug?

 

Please try out with the attached certificate (removing the .txt ext).

 

Thanks,

-binlu

 

From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Bin Lu
Sent: Wednesday, September 04, 2013 6:09 PM
To: openssl-users@openssl.org
Subject: multi-byte subject DN display

 

Hi,

 

This looks too easy but I am stuck … I am trying to display the subject name of 
a certificate which contains multi-byte characters. I tried 

 

$ openssl x509 –in cert_file -noout –subject –nameopt RFC2253 ( or 
oneline,-esc_msb)

 

And display the output in a web browser (IE or firefox) with character encoding 
set to UTF-8, neither gives me the right display.

 

Am I missing something? The characters are displayed correctly in the windows 
certificate viewer.

 

Thanks,

-binlu

 

Re: asn1 encoding routines error: x509_extension, from ssl3_get_server_cert

[Frank Migge]

Dear Mithun,

I came across this thread by researching the same question:
  Does openssl support S/MIME Capabilities certificate extension? 

For the following shortened code:

 /* display the cert extension list here */
 for (i=0; isk_X509_EXTENSION_num(ext_list); i++) {
ASN1_OBJECT *obj;
X509_EXTENSION *ext;

ext = sk_X509_EXTENSION_value(ext_list, i);
obj = X509_EXTENSION_get_object(ext);

// ommitting a few fprintf lines of output formatting
i2a_ASN1_OBJECT(outbio, obj);
// ommitting a few fprintf lines of output formatting

if (!X509V3_EXT_print(outbio, ext, 0, 0)) {
/* Some extensions (i.e. LogoType) have no handling*
 * defined, we need to print their content as hex data */
  fprintf(cgiOut, %*s, 0, );
  M_ASN1_OCTET_STRING_print(outbio, ext-value);
}

...used with a CSR having that extension set, I get this output:

S/MIME Capabilities

050...*.H.. ..0...*.H.. ..0...+0 ..*.H.. ..

It seems that X509V3_EXT_print() fails to decode, and 
M_ASN1_OCTET_STRING_print() kicks in to show the raw content.

OpenSSL knows about the S/MIME Capabilities OID (1.2.840.113549.1.9.15
per RFC4262),  but it seems there is no handling for the ASN.1 sequence 
underneath.

There is a related a href=http://www.mail-archive.com/openssl-
us...@openssl.org/msg58514.htmlold thread/a from 2009 with the recipe 
for manually adding the SMIME Capabilities to openssl.cnf.

I hope this helps!
Frank

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org