Hi ,
Since openssl.1.0.1c doesn't support ECDHE-ECDSA-AES128-CCM cipher suite,
I added this support in the openssl code.
It works fine with ECC certificates which are not self-signed.
When I process my ECC self-signed certificate, my webserver throughing X5*
On 31-07-2013 08:22, Indtiny s wrote:
Hi ,
Since openssl.1.0.1c doesn't support ECDHE-ECDSA-AES128-CCM cipher
suite, I added this support in the openssl code.
It works fine with ECC certificates which are not self-signed.
When I process my ECC self-signed certificate, my webserver throughing
-Original Message-
From: Jakob Bohm
On 30-07-2013 20:53, Walter H. wrote:
On 30.07.2013 19:51, Eisenacher, Patrick wrote:
In Boolean logic, we have the following possibilities:
- Root is trusted, so the revocation is valid, so the root is not
trusted. This is a
Hi
We are using openssl 0.9.8 in our application.
Things are working fine and suddenly we are having .
Linux awtah.dispatchserver1 3.6.11-1.fc16.i686 #1 SMP Mon Dec 17 21:36:23 UTC
2012 i686 i686 i386 GNU/Linux
error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record
anyone?
--
View this message in context:
http://openssl.6102.n7.nabble.com/SUIT-B-supported-cert-keys-tp45753p46006.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project
On 31-07-2013 11:02, Eisenacher, Patrick wrote:
-Original Message-
From: Jakob Bohm
On 30-07-2013 20:53, Walter H. wrote:
On 30.07.2013 19:51, Eisenacher, Patrick wrote:
In Boolean logic, we have the following possibilities:
- Root is trusted, so the revocation is valid, so the root
On 31-07-2013 11:16, Rajeev Tomar wrote:
Hi
We are using openssl 0.9.8 in our application.
Things are working fine and suddenly we are having .
Linux awtah.dispatchserver1 3.6.11-1.fc16.i686 #1 SMP Mon Dec 17
21:36:23 UTC 2012 i686 i686 i386 GNU/Linux
error:1408F119:SSL
-Original Message-
From: Jakob Bohm
On 31-07-2013 11:02, Eisenacher, Patrick wrote:
-Original Message-
From: Jakob Bohm
On 30-07-2013 20:53, Walter H. wrote:
On 30.07.2013 19:51, Eisenacher, Patrick wrote:
Jakob, I don't understand your reasoning here.
You
Hi ,
If there are no v3 extensions in the certificate, verify goes fine ,
If I add keyUsage , I get the below error .
*X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE*
But as per standard which I have follow for certficate generation , I have
to create the certificate with these extensions .
is
Hi All,
I am using openssl-1.0.1c in our project.when SSL_shutdown(ssl) get
executed it returns 0.If I get return value zero then calling the same
SSL_shutdown(ssl) again.In 2nd time it return -1. Can any one tell me how
to shutdown ssl context ? How can I execute SSL_shutdown(ssl) , so
Eisenacher, Patrick wrote:
-Original Message-
From: Jakob Bohm
On 31-07-2013 11:02, Eisenacher, Patrick wrote:
-Original Message-
From: Jakob Bohm
On 30-07-2013 20:53, Walter H. wrote:
On 30.07.2013 19:51, Eisenacher, Patrick wrote:
Jakob, I don't
On 31-07-2013 16:01, Walter H. wrote:
Eisenacher, Patrick wrote:
-Original Message-
From: Jakob Bohm
On 31-07-2013 11:02, Eisenacher, Patrick wrote:
-Original Message-
From: Jakob Bohm
On 30-07-2013 20:53, Walter H. wrote:
On 30.07.2013 19:51, Eisenacher, Patrick wrote:
On 31.07.2013 16:47, Jakob Bohm wrote:
the only cert that can't be checked by OCSP is the root cert itself;
This is where I disagree, can you point me to an actual reason why
not, which is not refuted by my logical ABC argument above.
the Authority Information Access extension does not make
-Original Message-
From: Walter H.
Eisenacher, Patrick wrote:
-Original Message-
From: Jakob Bohm
As I said before, there's no pki-inherent mechanism to revoke a self signed
certificate other than to remove it from your truststore.
not really; a CA that has to revoke
This is not possible according to PKIX. RFC5280 states The trust anchor for
the certification path [of the crl] MUST be the same as the trust anchor used
to validate the target certificate.
The root certificate creates a crl-signing cert. The root certificate includes
a cRLDistributionPoint
On 31-07-2013 19:56, Salz, Rich wrote:
This is not possible according to PKIX. RFC5280 states The trust anchor for the
certification path [of the crl] MUST be the same as the trust anchor used to validate the
target certificate.
The root certificate creates a crl-signing cert. The root
Wouldn't it be just as good to have a cRLDistributionPoint which does not
restrict the available ReasonFlags and then put cACompromise in the CRL
if/when that disaster happens?
No because with my idea you are a priori restrict the crlDP to be only CA
revocation.
Wouldn't it be equally
On 31-07-2013 22:11, Salz, Rich wrote:
Wouldn't it be just as good to have a cRLDistributionPoint which does not restrict the
available ReasonFlags and then put cACompromise in the CRL if/when that
disaster happens?
No because with my idea you are a priori restrict the crlDP to be only CA
18 matches
Mail list logo