Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Dennis Clarke]

On 20/02/18 01:36 PM, Norm Green wrote:

Hi Dennis,

You're right, I did modify the config file...



I have managed to get to the link stage here and ran into some odd
 syntax issue.

Have to dig around and see what LDCMD was intended to be.

${LDCMD:-/opt/developerstudio12.6/bin/cc} -errfmt=error -erroff=%none 
-errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xc 
-xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -Qy -xs -g 
-xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=sparc64viiplus 
-xarch=sparcima -xchip=sparc64viiplus -xcache=64/64/2:11264/256/11 
-D_TS_ERRNO -D__EXTENSIONS__ -D_POSIX_C_SOURCE 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE  -L. -mt  \
-o apps/openssl apps/asn1pars.o apps/ca.o apps/ciphers.o 
apps/cms.o apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o 
apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o 
apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o 
apps/nseq.o apps/ocsp.o apps/openssl.o apps/passwd.o apps/pkcs12.o 
apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o 
apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o 
apps/rsautl.o apps/s_client.o apps/s_server.o apps/s_time.o 
apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o 
apps/storeutl.o apps/ts.o apps/verify.o apps/version.o apps/x509.o \

  apps/libapps.a -lssl -lcrypto -lz -lsocket -lnsl -ldl -lpthread
Undefined   first referenced
 symbol in file
OPENSSL_LH_stats_bioapps/asn1pars.o
SSL_stateless   apps/s_server.o
BN_GENCB_free   apps/dhparam.o
SSL_CTX_set_ctlog_list_file apps/libapps.a(apps.o)
TLS_client_method   apps/ocsp.o
SSL_SESSION_get0_cipher apps/s_client.o
OPENSSL_strlcpy apps/ca.o
OPENSSL_strlcat apps/ca.o
OPENSSL_sk_pop_free apps/asn1pars.o
SSL_CTX_set_options apps/s_time.o
BN_is_zero  apps/ca.o
BIO_ADDRINFO_free   apps/libapps.a(s_socket.o)
BIO_ADDRINFO_next   apps/libapps.a(s_socket.o)
SSL_is_dtls apps/libapps.a(s_cb.o)
BIO_sock_info   apps/s_client.o
OpenSSL_version apps/speed.o
PKCS12_SAFEBAG_get0_attrs   apps/pkcs12.o
PKCS12_SAFEBAG_get_nid  apps/pkcs12.o
PKCS12_SAFEBAG_get0_safes   apps/pkcs12.o
PKCS12_SAFEBAG_get0_p8inf   apps/pkcs12.o
PKCS12_SAFEBAG_get0_pkcs8   apps/pkcs12.o
SSL_get0_dane_authority apps/libapps.a(s_cb.o)
PEM_write_bio_PrivateKey_traditional apps/pkcs8.o
CRYPTO_clear_free   apps/dgst.o
SSL_CTX_set_default_read_buffer_len apps/s_client.o
SSL_write_early_dataapps/s_client.o
RSA_check_key_exapps/rsa.o
SSL_get1_supported_ciphers  apps/ciphers.o
SSL_SESSION_get_max_early_data  apps/s_client.o
EVP_PKEY_meth_get0  apps/openssl.o
X509_STORE_CTX_set0_trusted_stack   apps/verify.o
PKCS12_SAFEBAG_get0_attrapps/pkcs12.o
PKCS12_SAFEBAG_get0_typeapps/pkcs12.o
PKCS12_SAFEBAG_get1_certapps/pkcs12.o
ASN1_TIME_set_string_X509   apps/ca.o
OPENSSL_sk_dup  apps/asn1pars.o
OPENSSL_sk_pop  apps/asn1pars.o
OPENSSL_sk_num  apps/asn1pars.o
OPENSSL_sk_new  apps/asn1pars.o
OPENSSL_sk_set  apps/asn1pars.o
EVP_PKEY_meth_get_count apps/openssl.o
BIO_ADDRINFO_protocol   apps/libapps.a(s_socket.o)
SCT_validation_status_stringapps/s_client.o
SSL_ct_is_enabled   apps/s_client.o
IDEA_optionsapps/speed.o
IDEA_set_encrypt_keyapps/speed.o
PKCS8_pkey_get0_attrs   apps/pkcs12.o
RSA_generate_multi_prime_keyapps/genrsa.o
X509_STORE_CTX_get_obj_by_subject   apps/crl.o
X509_CRL_get0_nextUpdateapps/crl.o
X509_CRL_get0_lastUpdateapps/crl.o
ASN1_ITEM_lookupapps/asn1pars.o
SSL_get0_peer_CA_list   apps/libapps.a(s_cb.o)
X509_CRL_set1_nextUpdateapps/ca.o
X509_CRL_set1_lastUpdateapps/ca.o
SSL_CTX_dane_enable apps/s_client.o
SSL_CTX_set_default_ctlog_list_file apps/libapps.a(apps.o)
SSL_CTX_set_keylog_callback apps/libapps.a(s_cb.o)
X509_CRL_get0_signature apps/crl.o
PKCS8_set0_pbe  apps/pkcs8.o
EVP_MD_CTX_new  apps/ocsp.o
PKCS12_get0_mac apps/pkcs12.o
SSL_set_options apps/s_client.o
ASYNC_WAIT_CTX_free apps/speed.o
SSL_get_options apps/s_server.o
OPENSSL_sk_free apps/asn1pars.o
OPENSSL_sk_find apps/asn1pars.o
OPENSSL_sk_push   

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Salz, Rich via openssl-users]

https://github.com/openssl/openssl/pull/5423


On 2/20/18, 2:10 PM, "Salz, Rich via openssl-users" 
 wrote:

I agree, let's just use malloc for the reasons you said.  PR later today.

On 2/20/18, 2:08 PM, "Viktor Dukhovni"  wrote:



> On Feb 20, 2018, at 11:36 AM, Norm Green 
 wrote:
> 
> Your patch tests clean, however there is an easier way which avoids 
malloc:

Great, so it was the unaligned "buf".  Great.  As for malloc vs. tricks 
to
align the stack-based array, I see little need to avoid malloc() this 
is a
test function, not a performance-critical library function.  Exercising
OPENSSL_malloc() is arguably a feature. :-)

That said, I have no religion on which approach is taken to align "buf".
I prefer "malloc" because it unasks the question of which type to use
in an array or union to ensure the "proper" alignment.  Using any of
"long" or "long long" is likely good enough, but could prove more 
fragile
as the code evolves.

-- 
Viktor.

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


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


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

[openssl-users] OpenSSL Version Definitions Issue on ARM

[Andrei Danaila]

Hi,

I am attempting to crosscompile openssl for ARM and am having some issues when 
linking an external application to the crosscompiled OpenSSL version.

I am compiling OpenSSL like so:
./Configure linux-generic32 shared \
 --prefix=/openssl_libs \
 --openssldir=/openssl_libs \
 
--cross-compile-prefix=/usr/local/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-
make depend
make -j8
make install

What I am finding however is that there is no version definitions in the 
generated .so. This causes any other application that I link against the 
generated .so, to expect the exact same version as the .so, in this case 
lib.so.1.0.0.

objdump --private-headers libssl.so.1.0.0

[...snip...]

Version References:
  required from libc.so.6:
0x0d696914 0x00 02 GLIBC_2.4

Whereas, if I look on the OpenSSL library which ships on my ubuntu box, I see:
Version definitions:
1 0x01 0x09bbb660 libssl.so.1.0.0
2 0x00 0x066a2b20 OPENSSL_1.0.0
3 0x00 0x066a2b21 OPENSSL_1.0.1
OPENSSL_1.0.0 
4 0x00 0x06a2b214 OPENSSL_1.0.1d
OPENSSL_1.0.1 
5 0x00 0x066a2b22 OPENSSL_1.0.2
OPENSSL_1.0.1d 
6 0x00 0x06a2b2e7 OPENSSL_1.0.2g
OPENSSL_1.0.2 
Version References:
  required from libc.so.6:
0x06969194 0x00 14 GLIBC_2.14
0x0d696914 0x00 13 GLIBC_2.4
0x09691974 0x00 11 GLIBC_2.3.4
0x09691a75 0x00 09 GLIBC_2.2.5
  required from libcrypto.so.1.0.0:
0x06a2b214 0x00 12 OPENSSL_1.0.1d
0x066a2b21 0x00 10 OPENSSL_1.0.1
0x066a2b22 0x00 08 OPENSSL_1.0.2
0x066a2b20 0x00 07 OPENSSL_1.0.0


Any insight would be greatly appreciated.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Loading CA from memory

[Devchandra L Meetei]

Thanks Viktor
As usual, Your answer throws light. Now, it is time to get started.
Will revert if got obstructed on the way

On Wed, Feb 21, 2018 at 9:58 AM, Viktor Dukhovni  wrote:

>
>
> > On Feb 20, 2018, at 12:58 PM, Devchandra L Meetei 
> wrote:
> >
> > By the way, Is there any plan to port SSL_CTX_load_verify_mem to openssl?
>
> The basic functionality is already there:
>
> If you want to parse in-memory PEM, see the use of
> PEM_X509_INFO_read_bio() [needs documentation] at:
>
>https://github.com/openssl/openssl/blob/master/apps/crl2p7.c#L179
>
> if have a PKCS7 DER or PEM structure, there are suitable functions for
> pulling
> out a chain from that.  Then you can set a "trusted stack" for your
> X509_STORE_CTX.
>
> --
> Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Warm Regards
--Dev
OpenPegasus Developer

"I'm one of those people that think Thomas Edison and the light bulb
changed the world more than Karl Marx ever did,” Steve Jobs
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Richard Levitte]

In message <6088d4cb-7566-c216-1e28-0892641cd...@blastwave.org> on Tue, 20 Feb 
2018 21:17:32 -0500, Dennis Clarke  said:

dclarke> Have to dig around and see what LDCMD was intended to be.

LDCMD is a convenience variable for some users to specify a different
command than the configured C compiler for linking programs.  So
unless you define it specifically, it will remain undefined.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Loading CA from memory

[Viktor Dukhovni]

> On Feb 20, 2018, at 12:58 PM, Devchandra L Meetei  wrote:
> 
> By the way, Is there any plan to port SSL_CTX_load_verify_mem to openssl?

The basic functionality is already there:

If you want to parse in-memory PEM, see the use of PEM_X509_INFO_read_bio() 
[needs documentation] at:

   https://github.com/openssl/openssl/blob/master/apps/crl2p7.c#L179

if have a PKCS7 DER or PEM structure, there are suitable functions for pulling
out a chain from that.  Then you can set a "trusted stack" for your 
X509_STORE_CTX.

-- 
Viktor.

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

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

[Jakob Bohm]

On 20/02/2018 11:04, Tobias Dussa (SCC) wrote:

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.

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
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

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

[Tobias Dussa (SCC)]

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.
-- 
I am Gates of Borg.  Resistance is futile.  You will be assimilated.
>From now on, you will finance... us.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Salz, Rich via openssl-users]

Would making buf a union also avoid the problem?

union { unsigned long dummy[2]; char buf[DATA_BUF_SIZE]; } d
and then replace 'buf' with 'd.buf' in the code?


On 2/20/18, 12:00 AM, "Viktor Dukhovni"  wrote:

On Mon, Feb 19, 2018 at 01:45:26PM -0800, Norm Green wrote:

> # ASN1_LONG_DATA:
> #   success: TRUE
> t@1 (l@1) signal BUS (invalid address alignment) in asn1_item_print_ctx at
> line 155 in file "tasn_prn.c"
>   155  || (it->utype != V_ASN1_BOOLEAN)) && *fld == NULL) {

Perhaps aligning the item buffer (by using malloc) will help, does
the patch below address the problem?

diff --git a/test/asn1_encode_test.c b/test/asn1_encode_test.c
index e9f459ad65..77fa9b5954 100644
--- a/test/asn1_encode_test.c
+++ b/test/asn1_encode_test.c
@@ -709,15 +709,19 @@ static int do_encode_custom(EXPECTED *input,
 static int do_print_item(const TEST_PACKAGE *package)
 {
 #define DATA_BUF_SIZE 256
-unsigned char buf[DATA_BUF_SIZE];
 const ASN1_ITEM *i = ASN1_ITEM_ptr(package->asn1_type);
-ASN1_VALUE *o = (ASN1_VALUE *)
+ASN1_VALUE *o = OPENSSL_malloc(DATA_BUF_SIZE);
 int ret;
 
 OPENSSL_assert(package->encode_expectations_elem_size <= 
DATA_BUF_SIZE);
 
-(void)RAND_bytes(buf, (int)package->encode_expectations_elem_size);
+if (o == NULL)
+return 0;
+
+(void)RAND_bytes((unsigned char *)o,
+ (int)package->encode_expectations_elem_size);
 ret = ASN1_item_print(bio_err, o, 0, i, NULL);
+OPENSSL_free(o);
 
 return ret;
 }

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


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

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Norm Green
> Sent: Monday, February 19, 2018 17:02
> To: Benjamin Kaduk; openssl-users@openssl.org
> Subject: Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC
> 
> For the failure in secmemtst, it appears that secure memory is not
> enabled per this code in ./crypto/mem_sec.c
> 
>   23 /* e_os.h includes unistd.h, which defines _POSIX_VERSION */
>   24 #if !defined(OPENSSL_NO_SECURE_MEMORY) &&
> defined(OPENSSL_SYS_UNIX) \
>   25 && defined(_POSIX_VERSION) && _POSIX_VERSION >= 200112L
>   26 # define IMPLEMENTED
>   27 # include 
>   28 # include 
>   29 # include 
>   30 # include 
>   31 # include 
>   32 # if defined(OPENSSL_SYS_LINUX)
>   33 #  include 
>   34 #  include 
>   35 #  include 
>   36 # endif
>   37 # include 
>   38 # include 
>   39 # include 
>   40 #endif
> 
> 
> 
> Solaris has this in sys/unistd.h
> 
> #ifndef _POSIX_VERSION
> #ifdef  _XPG6
> #define _POSIX_VERSION  200112L /* Supports IEEE Std 1003.1-2001 */
> #else
> #define _POSIX_VERSION  199506L /* Supports POSIX-1c DIS */
> #endif
> #endif /* _POSIX_VERSION */
> 
> I'm building with the native Oracle Solaris compiler which apparently
> does not define these macros.

Not by default. The comments in /usr/include/sys/feature_tests.h (on a Solaris 
system) explain this in excruciating detail, but in short you need either 
-DPOSIX_C_SOURCE=200112L or -D_XOPEN_SOURCE=600 (or the equivalent in the code) 
to compile with XPG6 (aka IEEE 1003.1-2001).

Solaris has always (well, since Solaris 2) been a bit cautious about making new 
standards the default, preferring backward compatibility as the default and 
requiring applications that want new features to set the appropriate feature 
macros. In this case, that's one of the two macros I listed above.

One of them should probably be added to the appropriate entries in Configure. I 
don't think it much matters which one; they ought to have the same effect, and 
neither is particularly clear to people who haven't had to dig into this stuff.

Disclaimer: I haven't tested this (in the OpenSSL case), just confirmed what 
feature_tests.h says.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Viktor Dukhovni]

On Tue, Feb 20, 2018 at 01:26:02PM +, Salz, Rich via openssl-users wrote:
> Would making buf a union also avoid the problem?
> 
>   union { unsigned long dummy[2]; char buf[DATA_BUF_SIZE]; } d
> and then replace 'buf' with 'd.buf' in the code?

If alignment of "buf" is the issue, then yes, a suitable union
would be an alternative to using malloc.  We could make the union:

union {
unsigned long long dummyl;
ossl_uintmax_t dummym;
char  *dummyp;
char buf[DATA_BUF_SIZE];
} d;

just in case that's what it takes for the required alignment.  But,
OPENSSL_malloc() should do the job simply, without such hoop jumping.

Either way, the OP should confirm that aligning "buf" solves the
reported problem.

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

Re: [openssl-users] How to make OpenSSL engine usage application specific?

[Linsell, StevenX]

> On Mon, 19 Feb 2018 Jayalakshmi Bhat wrote:
> 
> Engine usage is application specific.There are couple of applications
> dependent on RSA TPM? engine. And are few applications dependent on
> RSA smart card engine.?
> 
> We wanted to know if there are any APIs provided by OpenSSL to make the
> engine usage application specific? Is there any way we can make OpenSSL
> chose specific engine for
> 
> specific application.
> 

I think but don't quote me that if your applications are using the openssl.cnf 
file to configure the
engine you are going to use, then the OPENSSL_CONF environment variable will 
allow you to
control the configuration file loaded by OpenSSL. This allows you to have 
application specific 
configuration files that load the engine you require and make it the default 
engine. 
This is dependent on your application having been built with OPENSSL_LOAD_CONF 
defined.
You can also control the config file loaded programmatically via OPENSSL_config.

The alternative is loading your engine programmatically such as nginx does:
https://github.com/nginx/nginx/blob/master/src/event/ngx_event_openssl.c#L4193-L4237
and use ENGINE_set_default to make the engine you require the default for that 
application.
Of course that is only useful if you are in control of your applications source 
code.

There are more details here:
https://wiki.openssl.org/index.php/Library_Initialization
https://www.openssl.org/docs/manmaster/man5/config.html

Steve Linsell   Intel Shannon DCG/CID Software Development Team
stevenx.lins...@intel.com


--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.

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

Re: [openssl-users] Loading CA from memory

[Jakob Bohm]

On 20/02/2018 16:38, Devchandra L Meetei wrote:
I have been looking for  API like `SSL_CTX_load_verify_mem` which will 
load

CA[s] from mem buffer.

Looks like OpenSSL does not have it yet, Is there any other way to 
work around

this ?



I think it can be done step by step, at least in 1.0.x:

First allocate an empty STACK_OF X509 certificates

Then loop over your in-memory CA certificates, passing each to d2i_X509, 
then adding the resulting X509 object to the stack.


Finally pass that stack as the CA collection to an appropriate SSL_CTX 
function.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

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

[Tobias Dussa (SCC)]

Hi,

On Wed, Feb 21, 2018 at 01:04:17AM +0900, Frank Migge wrote:
> >> 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.

That's about what I thought I figured out, yeah. :)

> 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.

... and that, unfortunately, is about what I concluded as well. Bummer. ;-)

But thanks a lot for your thoughts (also to Jakob and Viktor)! :)

Cheers,
Toby.
-- 
To the systems programmer, users and applications serve only to provide
a test load.  


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Loading CA from memory

[Devchandra L Meetei]

I have been looking for  API like `SSL_CTX_load_verify_mem` which will load
CA[s] from mem buffer.

Looks like OpenSSL does not have it yet, Is there any other way to work
around
this ?

-- 
Warm Regards
--Dev
OpenPegasus Developer

"I'm one of those people that think Thomas Edison and the light bulb
changed the world more than Karl Marx ever did,” Steve Jobs
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Tobias Dussa (SCC)]

Hi,

On Tue, Feb 20, 2018 at 01:27:51PM +, Viktor Dukhovni wrote:
> > 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.
> Do any of the PKCS#12 key derivation functions implement the same
> password -> key algorithm as is used in OpenSSL's PEM password to
> key mapping for private keys?  I suspect that might be another
> problem area.

Uh...  Good point.  Didn't have that on the radar actually.

Thanks!

Cheers,
Toby.
-- 
We're Germans and we use Unix.  That's a combination of two demographic
groups known to have no sense of humour whatsoever.
  ---Hanno Mueller in de.comp.os.unix.programming


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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] 1.1.1 pre1 tests failing on Solaris SPARC

[Norm Green]

Hi Viktor,

Your patch tests clean, however there is an easier way which avoids malloc:

Norm


Index: test/asn1_encode_test.c
===
--- test/asn1_encode_test.c (revision 43654)
+++ test/asn1_encode_test.c (working copy)
@@ -706,15 +706,16 @@
 return ret;
 }

 static int do_print_item(const TEST_PACKAGE *package)
 {
 #define DATA_BUF_SIZE 256
-    unsigned char buf[DATA_BUF_SIZE];
+    uint64_t _buf[DATA_BUF_SIZE / sizeof(uint64_t)];/* force 8-byte 
alignment */

+    unsigned char *buf = (unsigned char *) _buf;
 const ASN1_ITEM *i = ASN1_ITEM_ptr(package->asn1_type);
-    ASN1_VALUE *o = (ASN1_VALUE *)
+    ASN1_VALUE *o = (ASN1_VALUE *)buf;
 int ret;

OPENSSL_assert(package->encode_expectations_elem_size <= DATA_BUF_SIZE);

 (void)RAND_bytes(buf, (int)package->encode_expectations_elem_size);
 ret = ASN1_item_print(bio_err, o, 0, i, NULL);




On 2/19/2018 9:00 PM, Viktor Dukhovni wrote:

On Mon, Feb 19, 2018 at 01:45:26PM -0800, Norm Green wrote:


# ASN1_LONG_DATA:
#   success: TRUE
t@1 (l@1) signal BUS (invalid address alignment) in asn1_item_print_ctx at
line 155 in file "tasn_prn.c"
   155  || (it->utype != V_ASN1_BOOLEAN)) && *fld == NULL) {

Perhaps aligning the item buffer (by using malloc) will help, does
the patch below address the problem?

diff --git a/test/asn1_encode_test.c b/test/asn1_encode_test.c
index e9f459ad65..77fa9b5954 100644
--- a/test/asn1_encode_test.c
+++ b/test/asn1_encode_test.c
@@ -709,15 +709,19 @@ static int do_encode_custom(EXPECTED *input,
  static int do_print_item(const TEST_PACKAGE *package)
  {
  #define DATA_BUF_SIZE 256
-unsigned char buf[DATA_BUF_SIZE];
  const ASN1_ITEM *i = ASN1_ITEM_ptr(package->asn1_type);
-ASN1_VALUE *o = (ASN1_VALUE *)
+ASN1_VALUE *o = OPENSSL_malloc(DATA_BUF_SIZE);
  int ret;
  
  OPENSSL_assert(package->encode_expectations_elem_size <= DATA_BUF_SIZE);
  
-(void)RAND_bytes(buf, (int)package->encode_expectations_elem_size);

+if (o == NULL)
+return 0;
+
+(void)RAND_bytes((unsigned char *)o,
+ (int)package->encode_expectations_elem_size);
  ret = ASN1_item_print(bio_err, o, 0, i, NULL);
+OPENSSL_free(o);
  
  return ret;

  }



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

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Dennis Clarke]

On 20/02/18 12:47 PM, Norm Green wrote:

On 2/20/2018 5:43 AM, Michael Wojcik wrote:
Not by default. The comments in /usr/include/sys/feature_tests.h (on a 
Solaris system) explain this in excruciating detail, but in short you 
need either -DPOSIX_C_SOURCE=200112L or -D_XOPEN_SOURCE=600 (or the 
equivalent in the code) to compile with XPG6 (aka IEEE 1003.1-2001).
Thanks for the suggestions Michael.  Neither resolves the problem. In 
fact, adding -D_XOPEN_SOURCE=600 causes a new problem:


/opt/solarisstudio12.3/bin/c99  -I. -Icrypto/include -Iinclude -m64 
-xtarget=ultra2 -D_XOPEN_SOURCE=600 -xstrconst -Xa -DB_ENDIAN -DBN_DIV2W 
-KPIC -xildoff -mt -xcode=pic32 -g -DDSO_DLFCN -DHAVE_DLFCN_H 
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM 
-DPOLY1305_ASM -DFILIO_H -DB_ENDIAN -DBN_DIV2W -D_REENTRANT 
-DOPENSSLDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/ssl\"" 
-DENGINESDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/lib/engines-1.1\"" 
-c -o crypto/bio/b_addr.o crypto/bio/b_addr.c

"crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXHOST
"crypto/bio/b_addr.c", line 198: variable length array can not be 
initialized: host

"crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXSERV
"crypto/bio/b_addr.c", line 198: variable length array can not be 
initialized: serv

c99: acomp failed for crypto/bio/b_addr.c
Makefile:881: recipe for target 'crypto/bio/b_addr.o' failed


I also tried building with c99 instead of cc, without success.




Is there a handy source tarball somewhere so that I may also have a
look at this?  I have had good success in the past with both c99 and
with fairly restrictive CFLAGS so I would like to look into this
also.

Dennis



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

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Norm Green]

Just download and build v1.1.1 pre alpha 1 on Solaris.  It's on 
ftp.openssl.org.  That's all I did.  Configure using 
solaris64-sparcv9-cc .  I'm using Solaris studio 12.3.


Norm


On 2/20/2018 10:01 AM, Dennis Clarke wrote:

On 20/02/18 12:47 PM, Norm Green wrote:

On 2/20/2018 5:43 AM, Michael Wojcik wrote:
Not by default. The comments in /usr/include/sys/feature_tests.h (on 
a Solaris system) explain this in excruciating detail, but in short 
you need either -DPOSIX_C_SOURCE=200112L or -D_XOPEN_SOURCE=600 (or 
the equivalent in the code) to compile with XPG6 (aka IEEE 
1003.1-2001).
Thanks for the suggestions Michael.  Neither resolves the problem. In 
fact, adding -D_XOPEN_SOURCE=600 causes a new problem:


/opt/solarisstudio12.3/bin/c99  -I. -Icrypto/include -Iinclude -m64 
-xtarget=ultra2 -D_XOPEN_SOURCE=600 -xstrconst -Xa -DB_ENDIAN 
-DBN_DIV2W -KPIC -xildoff -mt -xcode=pic32 -g -DDSO_DLFCN 
-DHAVE_DLFCN_H -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC 
-DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM -DPOLY1305_ASM -DFILIO_H -DB_ENDIAN -DBN_DIV2W 
-D_REENTRANT 
-DOPENSSLDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/ssl\"" 
-DENGINESDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/lib/engines-1.1\"" 
-c -o crypto/bio/b_addr.o crypto/bio/b_addr.c

"crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXHOST
"crypto/bio/b_addr.c", line 198: variable length array can not be 
initialized: host

"crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXSERV
"crypto/bio/b_addr.c", line 198: variable length array can not be 
initialized: serv

c99: acomp failed for crypto/bio/b_addr.c
Makefile:881: recipe for target 'crypto/bio/b_addr.o' failed


I also tried building with c99 instead of cc, without success.




Is there a handy source tarball somewhere so that I may also have a
look at this?  I have had good success in the past with both c99 and
with fairly restrictive CFLAGS so I would like to look into this
also.

Dennis





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

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Dennis Clarke]

On 20/02/18 01:50 PM, Dennis Clarke wrote:

On 20/02/18 01:36 PM, Norm Green wrote:


Making progress here ...

/opt/developerstudio12.6/bin/c99  -I. -Icrypto/include -Iinclude 
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 
-xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc 
-ftrap=%none -Qy -xs -g -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 
-D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -KPIC 
-DDSO_DLFCN -DHAVE_DLFCN_H -DZLIB -DNDEBUG -DOPENSSL_NO_STATIC_ENGINE 
-DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM 
-I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE 
-D_TS_ERRNO -DOPENSSLDIR="\"/usr/local/ssl\"" 
-DENGINESDIR="\"/usr/local/lib/engines-1.1\""  -c -o 
crypto/bio/bss_bio.o crypto/bio/bss_bio.c

"crypto/bio/bss_bio.c", line 244: error: undefined symbol: OSSL_SSIZE_MAX
"crypto/bio/bss_bio.c", line 400: error: undefined symbol: OSSL_SSIZE_MAX
c99: acomp failed for crypto/bio/bss_bio.c
gmake[1]: *** [Makefile:1781: crypto/bio/bss_bio.o] Error 2
gmake[1]: Leaving directory 
'/usr/local/build/openssl-1.1.1-pre1_SunOS5.10_sparcv9.001'

gmake: *** [Makefile:143: all] Error 2
corv $

let me track down that undef there


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

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Erik Forsberg]

>-- Original Message --
>
>On 20/02/18 12:47 PM, Norm Green wrote:
>> On 2/20/2018 5:43 AM, Michael Wojcik wrote:
>>> Not by default. The comments in /usr/include/sys/feature_tests.h (on a 
>>> Solaris system) explain this in excruciating detail, but in short you 
>>> need either -DPOSIX_C_SOURCE=200112L or -D_XOPEN_SOURCE=600 (or the 
>>> equivalent in the code) to compile with XPG6 (aka IEEE 1003.1-2001).
>> Thanks for the suggestions Michael.  Neither resolves the problem. In 
>> fact, adding -D_XOPEN_SOURCE=600 causes a new problem:
>> 
>> /opt/solarisstudio12.3/bin/c99  -I. -Icrypto/include -Iinclude -m64 
>> -xtarget=ultra2 -D_XOPEN_SOURCE=600 -xstrconst -Xa -DB_ENDIAN -DBN_DIV2W 
>> -KPIC -xildoff -mt -xcode=pic32 -g -DDSO_DLFCN -DHAVE_DLFCN_H 
>> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ 
>> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
>> -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM 
>> -DPOLY1305_ASM -DFILIO_H -DB_ENDIAN -DBN_DIV2W -D_REENTRANT 
>> -DOPENSSLDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/ssl\""
>>  
>> -DENGINESDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/lib/engines-1.1\""
>>  
>> -c -o crypto/bio/b_addr.o crypto/bio/b_addr.c
>> "crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXHOST
>> "crypto/bio/b_addr.c", line 198: variable length array can not be 
>> initialized: host
>> "crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXSERV
>> "crypto/bio/b_addr.c", line 198: variable length array can not be 
>> initialized: serv
>> c99: acomp failed for crypto/bio/b_addr.c
>> Makefile:881: recipe for target 'crypto/bio/b_addr.o' failed
>> 
>> 
>> I also tried building with c99 instead of cc, without success.
>> 
>

I build my Solaris OpenSSL binaries using studo compiler 12.4 cc -xc99
Havent tried latest 1.1.1 snapshot yet though, probably a good time


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

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Dennis Clarke]

On 20/02/18 02:06 PM, Erik Forsberg wrote:



-- Original Message --

On 20/02/18 12:47 PM, Norm Green wrote:

On 2/20/2018 5:43 AM, Michael Wojcik wrote:

<... snippage ...>


I also tried building with c99 instead of cc, without success.





I build my Solaris OpenSSL binaries using studo compiler 12.4 cc -xc99
Havent tried latest 1.1.1 snapshot yet though, probably a good time



working on it now .. gimme a few coffee cups to dig into this.

Dennis


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

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Viktor Dukhovni]

> On Feb 20, 2018, at 11:36 AM, Norm Green  
> wrote:
> 
> Your patch tests clean, however there is an easier way which avoids malloc:

Great, so it was the unaligned "buf".  Great.  As for malloc vs. tricks to
align the stack-based array, I see little need to avoid malloc() this is a
test function, not a performance-critical library function.  Exercising
OPENSSL_malloc() is arguably a feature. :-)

That said, I have no religion on which approach is taken to align "buf".
I prefer "malloc" because it unasks the question of which type to use
in an array or union to ensure the "proper" alignment.  Using any of
"long" or "long long" is likely good enough, but could prove more fragile
as the code evolves.

-- 
Viktor.

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

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Salz, Rich via openssl-users]

I agree, let's just use malloc for the reasons you said.  PR later today.

On 2/20/18, 2:08 PM, "Viktor Dukhovni"  wrote:



> On Feb 20, 2018, at 11:36 AM, Norm Green  
wrote:
> 
> Your patch tests clean, however there is an easier way which avoids 
malloc:

Great, so it was the unaligned "buf".  Great.  As for malloc vs. tricks to
align the stack-based array, I see little need to avoid malloc() this is a
test function, not a performance-critical library function.  Exercising
OPENSSL_malloc() is arguably a feature. :-)

That said, I have no religion on which approach is taken to align "buf".
I prefer "malloc" because it unasks the question of which type to use
in an array or union to ensure the "proper" alignment.  Using any of
"long" or "long long" is likely good enough, but could prove more fragile
as the code evolves.

-- 
Viktor.

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


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

Re: [openssl-users] Has client validated successfully?

[J Decker]

On Tue, Feb 13, 2018 at 9:33 AM, Emmanuel Deloget  wrote:

> Hello,
>
> On Tue, Feb 13, 2018 at 7:14 AM, Kyle Hamilton  wrote:
>
> > The only thing that the server can know is whether the client has
> > terminated the connection with a fatal alert.  If the client validates
> > presented cert chains, then its continuation with the connection means
> > that it passed validation.  If the client does not, or ignores any
> > given error, then it doesn't mean that it passed validation.
> >
> > In other words, you can only know if the client's applied policy
> > allows the connection to continue.  You cannot know if the policy that
> > was applied was specifically related to the certificate chain
> > presented.
> >
> > -Kyle H
> >
> > On Mon, Feb 12, 2018 at 10:06 PM, J Decker  wrote:
> > > Is there a way for a server to know if the client verified the cert
> chain
> > > successfully or not?
> >
>
> ​From a security PoV, that doesn't help much. One can build a malicious
> version of openvpn that will tell you "everything's ok" (or "it failed!",
> depending of its goal)​. The server should not make any decision w.r.t. the
> client state (that's more or less what is implied by Kyle's answer ; I just
> wanted to stress it).
>
>
Yes that is true however here's the scenario.
Client does a verification and passes or fails, and via the SSL layer I can
query if the client validated the certificate.
If it failed, provide a option for the client to get a renewed certificate
for verification.  If success, no action.
If an actor lies in this scenario he answers
lies *yes* and didn't, don't give him a means to actually verify. *noop*
lies *no* but did, then give him the root cert he already has *noop*

so I don't have to trust the reply I'm willing to give him the right
root.


> BR,
>
> -- Emmanuel Deloget
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Norm Green]

Hi Dennis,

You're right, I did modify the config file, sorry.  I did it so long ago 
I had forgotten.  I will email it to you shortly.


Norm


On 2/20/2018 10:14 AM, Dennis Clarke wrote:

On 20/02/18 01:11 PM, Norm Green wrote:
Just download and build v1.1.1 pre alpha 1 on Solaris.  It's on 
ftp.openssl.org.  That's all I did. Configure using 
solaris64-sparcv9-cc .  I'm using Solaris studio 12.3.


Did you modify the Configure file ?  Last time I looked the CFLAGS
as well as some other bits in there were terribly out of date and
not really what we want for a debug build.

Dennis



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

Re: [openssl-users] Has client validated successfully?

[Jochen Bern]

On 02/20/2018 06:34 PM, J Decker  wrote:
> Yes that is true however here's the scenario.
> Client does a verification and passes or fails, and via the SSL layer I can
> query if the client validated the certificate.
> If it failed, provide a option for the client to get a renewed certificate
> for verification.  If success, no action.
> If an actor lies in this scenario he answers
> lies *yes* and didn't, don't give him a means to actually verify. *noop*
> lies *no* but did, then give him the root cert he already has *noop*
> 
> so I don't have to trust the reply I'm willing to give him the right
> root.

That's nice from the server's POV, but the client REALLY REALLY SHOULD
NOT install and/or put trust into any CA certs it received in-band in a
connection that failed verification. The best (for you) it can do is to
store it and offer it to its user for additional verification and *then*
installation - and I'ld venture a guess that you'ld have to write such a
client yourself.

(And offering the *root* certificate isn't that far from the common
practice of a server sending *most* of its CA chain in addition to its
own certificate, anyway, so it's debatable whether you even *need* the
result of the client's verification as an input to send the root as well.)

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Salz, Rich via openssl-users]

 
> So ... this will be fun.
   
:)

Thanks for poking at this, folks.  Please take a look at the INSTALL and README 
files which do cover some of this prerequisites.  And then once you've "fixed" 
it, let us  know what we need to change!!

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

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Dennis Clarke]

On 20/02/18 01:11 PM, Norm Green wrote:
Just download and build v1.1.1 pre alpha 1 on Solaris.  It's on 
ftp.openssl.org.  That's all I did.  Configure using 
solaris64-sparcv9-cc .  I'm using Solaris studio 12.3.


Did you modify the Configure file ?  Last time I looked the CFLAGS
as well as some other bits in there were terribly out of date and
not really what we want for a debug build.

Dennis

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

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Dennis Clarke]

On 20/02/18 01:11 PM, Norm Green wrote:
Just download and build v1.1.1 pre alpha 1 on Solaris.  It's on 
ftp.openssl.org.  That's all I did.  Configure using 
solaris64-sparcv9-cc .  I'm using Solaris studio 12.3.


Let's have a look.


corv $ uname -a
SunOS corv 5.10 Generic_150400-59 sun4u sparc SUNW,SPARC-Enterprise

corv $ /opt/developerstudio12.6/bin/c99 -V
c99: Studio 12.6 Sun C 5.15 SunOS_sparc 2017/05/30

corv $ psrinfo -pv
The physical processor has 8 virtual processors (0-7)
  SPARC64-VII+ (portid 1024 impl 0x7 ver 0xa1 clock 2860 MHz)

corv $ pwd
/usr/local/src
corv $ cd ../build
corv $ gzip -dc ../src/openssl-1.1.1-pre1.tar.gz | tar -xf -
corv $ mv openssl-1.1.1-pre1 openssl-1.1.1-pre1_SunOS5.10_sparcv9.001
corv $ cd openssl-1.1.1-pre1_SunOS5.10_sparcv9.001
corv $ cp -p Configure Configure.backup
corv $ OPENSSL_SOURCE=`pwd`
corv $ export OPENSSL_SOURCE
corv $ echo $OPENSSL_SOURCE
/usr/local/build/openssl-1.1.1-pre1_SunOS5.10_sparcv9.001

OKay .. whats going on here ?

corv $ grep -i "sparc" Configure

Doesn't exist ... has to have been moved somewhere.

These two files make reference to solaris64 in some way :

./Configurations/10-main.conf
./config




Interesting comment :


 Solaris x86 with Sun C setups
# There used to be solaris-x86-cc target, but it was removed,
# primarily because vendor assembler can't assemble our modules
# with -KPIC flag. As result it, assembly support, was not even
# available as option. But its lack means lack of side-channel
# resistant code, which is incompatible with security by todays
# standards. Fortunately gcc is readily available prepackaged
# option, which we can firmly point at...
#
# On related note, solaris64-x86_64-cc target won't compile code
# paths utilizing AVX and post-Haswell instruction extensions.
# Consider switching to solaris64-x86_64-gcc even here...
#


Pre-packaged? Really ... let's not go down the route of argument today.


"solaris64-sparcv9-cc" => {
inherit_from => [ "solaris-sparcv7-cc", asm("sparcv9_asm") ],
cflags   => add_before("-xarch=v9"),
bn_ops   => "BN_LLONG RC4_CHAR",
multilib => "/64",
},


Actually xarch=v9 is wrong.  Should just say "sparc".

Well it looks like lots has changed ... so let me fish around in here
and find what is going on with Configure and its new sub-files and then
see if I can get a compile going as a debug build. Also I have gcc 7.2.0
here but there isn't any such thing as "pre-packaged".

Dennis








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

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Dennis Clarke]

On 20/02/18 01:36 PM, Norm Green wrote:

Hi Dennis,

You're right, I did modify the config file, sorry.  I did it so long ago 
I had forgotten.  I will email it to you shortly.




Not a problem .. everyone does.

I mean look at this mess if you don't :


corv $ ./Configure shared zlib threads solaris64-sparcv9-cc
Perl v5.10.0 required--this is only v5.8.4, stopped at ./Configure line 12.
BEGIN failed--compilation aborted at ./Configure line 12.
corv $

uh huh.

I have newer perl I built myself but I generally start with the baseline
 system stuff .. which is covered in dust and mold :

corv $ /usr/local/bin/perl -V
Summary of my perl5 (revision 5 version 26 subversion 0) configuration:
.
.
.


So ... this will be fun.

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

Re: [openssl-users] Has client validated successfully?

[Kyle Hamilton]

No, you cannot query the SSL layer to know if the client validated the
certificate.  SSL/TLS don't provide any means of querying the remote
side.

Here's how the workflow works:

1) client doesn't trust certificate, doesn't override distrust:
connection closes with fatal unknown_ca or expired_certificate alert.
2) client doesn't trust certificate, does override distrust:
connection continues.  No way to query if distrust was overridden.
3) client does trust certificate, no need to override: connection
continues.  No way to query if distrust was overridden.

There's no way for the server to know if the client trusts the
certificate, or if the client overrode the distrust.

There's generally also no way for Javascript on the client to know
this, either.  However, because this is a list about OpenSSL (and not
about any given application of OpenSSL, i.e. the web) it's not the
best place to ask about how to do this on the web.

Certificate chain updates (to avoid chain expiration) by the server
are expected to be done unilaterally, by the server operator.

If different certificate chains need to be provided to different
clients, the different clients can request different hostnames (via
the Server Name Indication extension) so the server can decide which
certificate chain to present.

As much as it sucks, this is the only server certificate selection
mechanism that exists in SSL/TLS.

-Kyle H

On Tue, Feb 20, 2018 at 9:34 AM, J Decker  wrote:
>
>
> On Tue, Feb 13, 2018 at 9:33 AM, Emmanuel Deloget  wrote:
>>
>> Hello,
>>
>> On Tue, Feb 13, 2018 at 7:14 AM, Kyle Hamilton  wrote:
>>
>> > The only thing that the server can know is whether the client has
>> > terminated the connection with a fatal alert.  If the client validates
>> > presented cert chains, then its continuation with the connection means
>> > that it passed validation.  If the client does not, or ignores any
>> > given error, then it doesn't mean that it passed validation.
>> >
>> > In other words, you can only know if the client's applied policy
>> > allows the connection to continue.  You cannot know if the policy that
>> > was applied was specifically related to the certificate chain
>> > presented.
>> >
>> > -Kyle H
>> >
>> > On Mon, Feb 12, 2018 at 10:06 PM, J Decker  wrote:
>> > > Is there a way for a server to know if the client verified the cert
>> > > chain
>> > > successfully or not?
>> >
>>
>> From a security PoV, that doesn't help much. One can build a malicious
>> version of openvpn that will tell you "everything's ok" (or "it failed!",
>> depending of its goal). The server should not make any decision w.r.t. the
>> client state (that's more or less what is implied by Kyle's answer ; I
>> just
>> wanted to stress it).
>>
>
> Yes that is true however here's the scenario.
> Client does a verification and passes or fails, and via the SSL layer I can
> query if the client validated the certificate.
> If it failed, provide a option for the client to get a renewed certificate
> for verification.  If success, no action.
> If an actor lies in this scenario he answers
> lies *yes* and didn't, don't give him a means to actually verify. *noop*
> lies *no* but did, then give him the root cert he already has *noop*
>
> so I don't have to trust the reply I'm willing to give him the right
> root.
>
>>
>> BR,
>>
>> -- Emmanuel Deloget
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Norm Green]

On 2/20/2018 5:43 AM, Michael Wojcik wrote:

Not by default. The comments in /usr/include/sys/feature_tests.h (on a Solaris 
system) explain this in excruciating detail, but in short you need either 
-DPOSIX_C_SOURCE=200112L or -D_XOPEN_SOURCE=600 (or the equivalent in the code) 
to compile with XPG6 (aka IEEE 1003.1-2001).
Thanks for the suggestions Michael.  Neither resolves the problem. In 
fact, adding -D_XOPEN_SOURCE=600 causes a new problem:


/opt/solarisstudio12.3/bin/c99  -I. -Icrypto/include -Iinclude -m64 
-xtarget=ultra2 -D_XOPEN_SOURCE=600 -xstrconst -Xa -DB_ENDIAN -DBN_DIV2W 
-KPIC -xildoff -mt -xcode=pic32 -g -DDSO_DLFCN -DHAVE_DLFCN_H 
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM 
-DPOLY1305_ASM -DFILIO_H -DB_ENDIAN -DBN_DIV2W -D_REENTRANT 
-DOPENSSLDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/ssl\"" 
-DENGINESDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/lib/engines-1.1\"" 
-c -o crypto/bio/b_addr.o crypto/bio/b_addr.c

"crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXHOST
"crypto/bio/b_addr.c", line 198: variable length array can not be 
initialized: host

"crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXSERV
"crypto/bio/b_addr.c", line 198: variable length array can not be 
initialized: serv

c99: acomp failed for crypto/bio/b_addr.c
Makefile:881: recipe for target 'crypto/bio/b_addr.o' failed


I also tried building with c99 instead of cc, without success.

Norm

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

Re: [openssl-users] Loading CA from memory

[Devchandra L Meetei]

Thanks Jakob for the hint
Let me try out the suggested approach.

By the way, Is there any plan to port SSL_CTX_load_verify_mem to openssl?

On Tue, Feb 20, 2018 at 9:23 PM, Jakob Bohm  wrote:

> On 20/02/2018 16:38, Devchandra L Meetei wrote:
>
>> I have been looking for  API like `SSL_CTX_load_verify_mem` which will
>> load
>> CA[s] from mem buffer.
>>
>> Looks like OpenSSL does not have it yet, Is there any other way to work
>> around
>> this ?
>>
>>
>> I think it can be done step by step, at least in 1.0.x:
>
> First allocate an empty STACK_OF X509 certificates
>
> Then loop over your in-memory CA certificates, passing each to d2i_X509,
> then adding the resulting X509 object to the stack.
>
> Finally pass that stack as the CA collection to an appropriate SSL_CTX
> function.
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Warm Regards
--Dev
OpenPegasus Developer

"I'm one of those people that think Thomas Edison and the light bulb
changed the world more than Karl Marx ever did,” Steve Jobs
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Tobias Dussa (SCC)]

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.
-- 
I know that you believe that you understood what you think I said,
but I am not sure you realize that what you heard is not what I meant.


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Viktor Dukhovni]

On Tue, Feb 20, 2018 at 12:23:14PM +0100, Jakob Bohm wrote:


> > 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?
>
> 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.

Do any of the PKCS#12 key derivation functions implement the same
password -> key algorithm as is used in OpenSSL's PEM password to
key mapping for private keys?  I suspect that might be another
problem area.

What combination of the "-keypbe", "-macalg", and "-maciter" options
yields a key derivation function that matches PEM?

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

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Dennis Clarke]

On 20/02/18 01:52 PM, Salz, Rich via openssl-users wrote:
  

 So ... this will be fun.

:)


Thanks for poking at this, folks.  Please take a look at the INSTALL and README files 
which do cover some of this prerequisites.  And then once you've "fixed" it, 
let us  know what we need to change!!



fixed? .. well .. hacked at for sure.

getting there .. hitting little snags as I go :

/opt/developerstudio12.6/bin/c99  -I. -Icrypto/include -Iinclude 
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 
-xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc 
-ftrap=%none -Qy -xs -g -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 
-xtarget=sparc64viiplus -xarch=sparcima -xchip=sparc64viiplus 
-xcache=64/64/2:11264/256/11 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS 
-D_LARGEFILE64_SOURCE -KPIC -DDSO_DLFCN -DHAVE_DLFCN_H -DZLIB -DNDEBUG 
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM 
-DPOLY1305_ASM -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS 
-D_LARGEFILE64_SOURCE -D_TS_ERRNO -DOPENSSLDIR="\"/usr/local/ssl\"" 
-DENGINESDIR="\"/usr/local/lib/engines-1.1\""  -c -o crypto/sparcv9cap.o 
crypto/sparcv9cap.c

"crypto/sparcv9cap.c", line 132: warning: no explicit type given
"crypto/sparcv9cap.c", line 132: error: syntax error before or at: 
common_jmp
"crypto/sparcv9cap.c", line 132: warning: old-style declaration or 
incorrect type for: common_jmp
"crypto/sparcv9cap.c", line 135: warning: implicit function declaration: 
siglongjmp
"crypto/sparcv9cap.c", line 214: warning: implicit function declaration: 
sigfillset
"crypto/sparcv9cap.c", line 215: warning: implicit function declaration: 
sigdelset
"crypto/sparcv9cap.c", line 223: warning: implicit function declaration: 
sigprocmask
"crypto/sparcv9cap.c", line 229: warning: implicit function declaration: 
sigaction
"crypto/sparcv9cap.c", line 233: warning: implicit function declaration: 
sigsetjmp

c99: acomp failed for crypto/sparcv9cap.c
gmake[1]: *** [Makefile:6253: crypto/sparcv9cap.o] Error 2
gmake[1]: Leaving directory 
'/usr/local/build/openssl-1.1.1-pre1_SunOS5.10_sparcv9.001'

gmake: *** [Makefile:143: all] Error 2
corv $

yep .


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