:6b:15:
5d:25:45:59:86:22:f6:de:06:db:0c:60:8e:30:32:45:d6:c6:
01:16:a3:94:9d:cb:4e:fd:a6:6b:a1:73
On Mon, Nov 17, 2014 at 3:06 PM, Fredrik Jansson
wrote:
> I actually got a bit further with a secp256r1 server certificate, I
> also changed the server certificate version fro
, 2014 at 1:19 PM, Fredrik Jansson
wrote:
> More tests as you suggested:
>
> openssl s_client -tls1_2 -connect XXX:9103
> openssl s_server -state -tls1_2 -cipher SUITEB128 -accept 9103
>
> Using default temp DH parameters
> ACCEPT
> SSL_accept:before/accept ini
hello C
ERROR
139990990374592:error:1408A0C1:SSL routines:ssl3_get_client_hello:no
shared cipher:s3_srvr.c:1398:
shutting down SSL
CONNECTION CLOSED
Warm regards,
Fredrik
On Mon, Nov 17, 2014 at 1:09 PM, Fredrik Jansson
wrote:
> Hi!
>
> I have tried with s_client, and I get the same erro
014, Fredrik Jansson wrote:
>
>> Some more info,
>>
>> SSL_get_ciphers on the server and client:
>> Info2014-Nov-17 10:48:26.961112 All.TLSVerbose
>> ECDHE-ECDSA-AES128-GCM-SHA256
>> Info2014-Nov-17 10:48:26.961114 All.TLSVerbose
>> ECDHE-ECD
listed
(among with several others).
Fredrik
On Mon, Nov 17, 2014 at 9:54 AM, Fredrik Jansson
wrote:
> Hi Steve!
>
> I remade the certs as below, but I still get the same error, i.e.
> 1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher.
>
> Anything else I can try
:77:ba:91:4b:34:4f:94:92:b1:a3:
da:5f:43:13:61:d0:02:bc:27:65:47:ac:ba:4e:79:13:84:cd:
eb:c6:5e:a3:94:e9:fa:48:48:e9:78:f9:d3
On Fri, Nov 14, 2014 at 11:32 PM, Dr. Stephen Henson wrote:
> On Fri, Nov 14, 2014, Fredrik Jansson wrote:
>
>> Hi Steve, thanks for
Fri, Nov 14, 2014, Fredrik Jansson wrote:
>
>> Hi!
>>
>> Thanks!
>>
>> I am using 1.0.2b3 on both server and client, and I have the call to
>> SSL_CTX_set_ecdh_auto, but still no luck.
>>
>> The exact code is as follows:
>>
>> 358
SSL_CTX_set_options(ctx_, SSL_OP_NO_TICKET);
415 SSL_CTX_set_session_cache_mode(ctx_, SSL_SESS_CACHE_BOTH);
416 SSL_CTX_sess_set_remove_cb(ctx_, ssl_remove_session_cb);
417 CertStore::setStoreInCTX(ctx_);
418 }
Warm regards,
Fredrik
On Fri, Nov 14, 2014 at 3:36 PM, Dr. Stephen Henson
Hi!
I am trying to force my TLS 1.2 connection into Suite B mode, but at
handshake I get an error "no shared cipher".
The server code is basically:
SSL_CTX_new(TLSv1_2_server_method());
//ECDSA cert is added to the ctx
SSL_CTX_use_certificate(ctx_, serverCert.cert.get())
SSL_CTX_use_PrivateKey(c
?
Warm regards,
Fredrik
On Mon, Oct 13, 2014 at 6:08 PM, Dr. Stephen Henson wrote:
> On Mon, Oct 13, 2014, Fredrik Jansson wrote:
>
>> Hi!
>>
>> I have a device where I cannot access the client certificate's private
>> key directly, but have access to verification
Hi Steve!
I will try to take that path, thank you!
//Fredrik
On Mon, Oct 13, 2014 at 6:08 PM, Dr. Stephen Henson wrote:
> On Mon, Oct 13, 2014, Fredrik Jansson wrote:
>
>> Hi!
>>
>> I have a device where I cannot access the client certificate's private
>&g
rt_cb function. I can convert the encoded cert to
a X509 structure and return that, but I cannot provide it with a
EVP_PKEY object.
Is there any way I can instruct any of the SSL_CTX, SSL or EVP_PKEY
objects to call a signature function (that I provide) during the
handshake?
Best regards,
Fredrik Ja
I have two CRL, one empty and one with a revoked certificate.
I create a X509_STORE and use X509_STORE_add_crl to add the empty CRL.
When verifying the certificate using the store, it verifies alright.
Then I add the CRL with the revoked cert to the same store, again
using X509_STORE_add_crl.
W
Hi!
Some example code to extract a cert from a P12 file:
BIO* certFile = BIO_new_file("cert path", "r");
PKCS12* p12 = nullptr;
X509* cert = nullptr;
if (!certFile) {
goto done;
}
p12 = d2i_PKCS12_bio(certFile, nullptr);
if (!
Mar 04, 2014, Fredrik Jansson wrote:
>
>> I am currently using DTLS v1.1 but with the introduction of v1.2 in OpenSSL
>> 1.0.1f I was hoping to be able to use AES CCM mode.
>>
>> We use PSK to key DTLS and the resulting algorithm is PSK-AES256-CBC-SHA.
>> Is it possi
I am currently using DTLS v1.1 but with the introduction of v1.2 in OpenSSL
1.0.1f I was hoping to be able to use AES CCM mode.
We use PSK to key DTLS and the resulting algorithm is PSK-AES256-CBC-SHA.
Is it possible to stick with PSK and migrate to AES CCM?
Best regards,
Fredrik
Hi Sravanthi,
I have implemented this as follows:
One thread per listen socket, calling DTLSv1_listen. This thread spawns one
thread per client and those treads call SSL_accept.
The listening threads share a single SSL_CTX, and each call to SSL_new is
protected by a mutex.
Each SSL object has a
04, 2013, Fredrik Jansson wrote:
>
> > Thanks, that did it!
> >
> > To try to understand the implications of this, if I add SSL_FIPS
> > to TLS1_TXT_PSK_WITH_AES_128_CBC_SHA and
> TLS1_TXT_PSK_WITH_AES_256_CBC_SHA,
> > am I violating the security policy? AES 128/256
2:31 PM, Dr. Stephen Henson wrote:
> On Mon, Nov 04, 2013, Fredrik Jansson wrote:
>
> > Steve, thanks for getting back!
> >
> > Since I could not reproduce this using s_client and s_server I set out to
> > take the code I am using into a sample project.
> >
>
Sun, Nov 3, 2013 at 4:15 PM, Dr. Stephen Henson wrote:
> On Fri, Oct 25, 2013, Fredrik Jansson wrote:
>
> >
> > I am trying to use DTLS with PSK (cipher: SSL_TXT_PSK). Everything works
> > well if I don't set OpenSSL in FIPS mode (FIPS_mode_set(1)).
> >
>
>
t;
}
before *p == SSL3_MT_CLIENT_HELLO, it works.
Should I report a bug?
Fredrik
On Fri, Oct 25, 2013 at 2:03 PM, Fredrik Jansson <
fredrik.jansson...@gmail.com> wrote:
> Hi!
>
>
> I am trying to use DTLS with PSK (cipher: SSL_TXT_PSK). Everything works
> well if
Hi!
I am trying to use DTLS with PSK (cipher: SSL_TXT_PSK). Everything works
well if I don't set OpenSSL in FIPS mode (FIPS_mode_set(1)).
If I do, I get crashes as below where p =0;
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffddffb700 (LWP 15278)]
0x7
Hi!
Note, this is OpenSSL 1.0.1c.
sha.h: int SHA512_Init(SHA512_CTX *c);
evp.h: const EVP_MD *EVP_sha512(void);
Best regards,
Fredrik
On Fri, Oct 4, 2013 at 9:44 AM, Gnanasekar R wrote:
> Hi,
>
> I would like to know if OpenSSL has support for SHA-512/224 and
> SHA-512/256. I see init functio
Hi!
I have managed to deadlock OpenSSL while running in FIPS mode.
The locking functions are setup according to mttest.c and th-lock.c using
pthread_mutex_.
Please note I have NOT explicitly set a thread id function.
Then env is:
openssl-1.0.1e
openssl-fips-2.0.5
RHEL 6 - 32 bit.
Please let me
e the client needs to take some
measure. The client happily keeps sending data.
Any help on how to resolve this would be greatly appreciated.
Best regards,
Fredrik Jansson
25 matches
Mail list logo
