> From: owner-openssl-us...@openssl.org On Behalf Of Harald Latzko
> Sent: Friday, 03 August, 2012 03:02
> Am 03.08.2012 um 03:55 schrieb Dave Thompson:
> Yes, the hash link (.0) exists and after the first
> connect failed, I double-checked the linked openSSL version
> against the commandline t
On Fri, Aug 03, 2012, Erik Tkal wrote:
> Hi Steve, here's the cert:
>
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number: 34474 (0x86aa)
> Signature Algorithm: ecdsa-with-SHA256
> Issuer: CN=eRoot1, OU=Engineering, O=Juniper Networks, Inc.,
> L=Westford, ST
Zitat von Nou Dadoun :
Starting to look at trying to port some of our code to windows 8
metro which deprecates winsock in favour of a new WinRT networking
api which appears to provide a much thicker/heavier weight
abstraction in which it's not clear how to make use of tools like
openssl.
Hi Steve, here's the cert:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 34474 (0x86aa)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=eRoot1, OU=Engineering, O=Juniper Networks, Inc.,
L=Westford, ST=MA, C=US
Validity
Not Before: Aug 1
Hello OpenSSL community,
I'm trying to work with FIPS-mode enabled OpenSSL library (version
2.0.1) on iOS platform, but unfortunately every time I try to enable
FIPS mode (via FIPS_module_mode_set), few self-tests fail.
Specifically these: FIPS_selftest_dsa(), FIPS_selftest_ecdsa() and
FIPS_selftes
On Fri, Aug 03, 2012, Erik Tkal wrote:
> I debugged this to see what is happening, and it seems that the server is
> looking at the configured certificate and key and deciding that the client
> needs to be sending 0xFF01 (it is finding NID_X9_62_prime_field as the field
> type). However, the c
I debugged this to see what is happening, and it seems that the server is
looking at the configured certificate and key and deciding that the client
needs to be sending 0xFF01 (it is finding NID_X9_62_prime_field as the field
type). However, the client is sending the full list of standard named
Starting to look at trying to port some of our code to windows 8 metro which
deprecates winsock in favour of a new WinRT networking api which appears to
provide a much thicker/heavier weight abstraction in which it's not clear how
to make use of tools like openssl.
Just wanted to throw out some
Hi,
I am using OpenSSL 1.0.1c 10 May 2012
I am trying to use cryptodev engine, so I did following steps
installed openssl with
./config DHAVE_CRYPTODEV
make
make install
installed *cryptodev driver *
tested with an application AES successful
In an application program
e = ENGINE_by_id("
Hello Jakob,
Am 03.08.2012 um 09:52 schrieb Jakob Bohm:
>> My assumption of a chain of trust is that the end of a trust chain is
>> reached (=a server or client certificate is seen as valid and secure) if the
>> whole chain of certificates ends in an entifiy where subject=issuer and
>> CA:true
On Fri, Aug 03, 2012, Jakob Bohm wrote:
> On 8/3/2012 10:32 AM, Maciej Pawlus wrote:
> >Hi,
> >
> >I need to sign mobileconfig file before sending it to the iOS device.
> >For this I want to call openssl as a separate process. However I do not
> >want to operate on physical files, as it requires a
On 8/3/2012 10:32 AM, Maciej Pawlus wrote:
Hi,
I need to sign mobileconfig file before sending it to the iOS device.
For this I want to call openssl as a separate process. However I do not
want to operate on physical files, as it requires a lot of read/write
operations which will slow down the w
On Fri, Aug 03, 2012, Saurabh Pandya wrote:
> Hi all,
>
> I am using server certificate "X" problematically with following API for each
> SSL * session. X is dynamically generated for each client, when its CA(s)
> as always same.
>
> SSL_use_certificate(this_ssl, X);
>
> It works fine
Hi,
I need to sign mobileconfig file before sending it to the iOS device. For
this I want to call openssl as a separate process. However I do not want to
operate on physical files, as it requires a lot of read/write operations
which will slow down the whole process and cause file handling issues.
On 8/3/2012 9:02 AM, Harald Latzko wrote:
Hello Dave,
Am 03.08.2012 um 03:55 schrieb Dave Thompson:
> Aside: it's a good thing you gave the server, because Outlook
> (which we use) blocks *.cer. I wish it didn't, but it does.
I've reached this "great" functionality last week, too. There's a
po
Hello Dave,
Am 03.08.2012 um 03:55 schrieb Dave Thompson:
> Aside: it's a good thing you gave the server, because Outlook
> (which we use) blocks *.cer. I wish it didn't, but it does.
I've reached this "great" functionality last week, too. There's a possibility
to allow filename extensions ins
16 matches
Mail list logo
