Matt,
Sorry for the confusion. In the first (correct) trace the client is
BoringSSL (webrtc) and the server hello comes from Janus (OpenSSL). In the
bad trace the Client is openSSL and the server is BoringSSL. The error
almost always seems to happen in this configuration (when client ==
openSSL,
Yes, if you never call FIPS_mode_set(), the POST will never run. I'll
defer to the experts on your other questions.
On 05/01/2015 05:10 PM, Bryan Call wrote:
So can I assume the FIPS POST has completed if I never call FIPS_mode_set()
in the code? I was confused about that.
When we call
On 01/05/15 02:11, faraz khan wrote:
Hi everyone,
This is my first time posting to this list - so if theres a better place
for this question please let me know.
The problem I'm trying to fix applies to the Janus webrtc gateway
(https://github.com/meetecho/janus-gateway) and my application
Hi,
I have a privatekey file written using the call PEM_write_bio_RSAPrivateKey
(...)
The file write operation has been successful.
However, when i am trying to read it via calls PEM_read_bio_PrivateKey(..)
or PEM_read_bio_RSAPrivateKey(..) , it is always returning NULL.
There is no encryption
Matt,
Thanks for taking the time to go through this. Unfortunately this error
only happens when WebRTC is acting as the server in the dtls handshake and
no logs (at all) seem to be printed but I think that's because openssl
logging is done in a different way in native WebRTC which I'm not
On 01/05/15 16:51, faraz khan wrote:
Matt,
Thanks for taking the time to go through this. Unfortunately this error
only happens when WebRTC is acting as the server in the dtls handshake
and no logs (at all) seem to be printed but I think that's because
openssl logging is done in a different
On 01/05/15 20:09, faraz khan wrote:
Matt,
Thanks again! To be precise webrtc is using boringssl (Google's fork of
openssl). From the commits it seems VERY recent but I'm unable to figure
out the last openssl merge-in. You think this could be the issue? Should
I try both with boringSSL (its
Matt,
Thanks again! To be precise webrtc is using boringssl (Google's fork of
openssl). From the commits it seems VERY recent but I'm unable to figure
out the last openssl merge-in. You think this could be the issue? Should I
try both with boringSSL (its kinda hard to compile webrtc with openSSL
Great Dave this did the trick.
Thanks,
Mark
Van: openssl-users [openssl-users-boun...@openssl.org] namens Dave Thompson
[dthomp...@prinpay.com]
Verzonden: vrijdag 1 mei 2015 6:59
Aan: openssl-users@openssl.org
Onderwerp: Re: [openssl-users] Error signing
On 01/05/15 02:11, faraz khan wrote:
Hi everyone,
This is my first time posting to this list - so if theres a better place
for this question please let me know.
The problem I'm trying to fix applies to the Janus webrtc gateway
(https://github.com/meetecho/janus-gateway) and my application
So can I assume the FIPS POST has completed if I never call FIPS_mode_set() in
the code? I was confused about that.
When we call SSL_read() and get a 0 byte return we call SSL_get_error() to see
if there was an error not not. Maybe there is a more efficient handle this,
like looking at the
On Fri, May 01, 2015 at 09:01:47PM +0100, Matt Caswell wrote:
On 01/05/15 20:09, faraz khan wrote:
Matt,
Thanks again! To be precise webrtc is using boringssl (Google's fork of
openssl). From the commits it seems VERY recent but I'm unable to figure
out the last openssl merge-in. You
Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors.
It appears your application is generating a lot of errors for some
reason. Never tried it myself, but you probably can't disable this lock
with multiple threads running. You should take a look at the error log
to identify
The changes to SSL_locking_callback() look good. But the code you've
added to SSL_CTX_add_extra_chain_cert_file() doesn't accomplish much.
You're checking if FIPS is on or off, then setting the FIPS mode to the
current setting, which is a no-op.
On 04/30/2015 09:49 PM, Bryan Call wrote:
Even a small convenience is still a convenience.
And eventually they add up.
Thanks for the comments - it's appreciated.
--
View this message in context:
http://openssl.6102.n7.nabble.com/SHA256-to-EVP-tp57774p57826.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
[resending from the correct email address; list moderator, if you see this
first, just delete the one in the non-member queue]
On 2/24/15 10:10 AM, Dr. Stephen Henson wrote:
So the embedded content type will be enveloped data?
If so first you
On Fri, May 01, 2015, Richard Welty wrote:
On 2/24/15 10:10 AM, Dr. Stephen Henson wrote:
So the embedded content type will be enveloped data?
If so first you can check that type using CMS_get0_eContentType().
Then you can use CMS_get0_content() to retrieve the embedded content as
Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors. It
appears your application is generating a lot of errors for some reason. Never
tried it myself, but you probably can't disable this lock with multiple
threads running. You should take a look at the error log to
18 matches
Mail list logo
