RE: Verification of a certificate chain
Hi Sven,
-Original Message-
From: Sven Reissmann
What I want to achieve is having a new rootCA, which replaces an
oldRootCA, which I am using until now.
So far the trust chain is: oldRoot - oldServerCert.
What I thought should be possible is building this trust chain:
oldRoot - newRoot - newSubCA - newServerCert
As Users are trusting oldRoot, changing the oldServerCert to
newServerCert is no problem. After some time, users would move trust to
newRoot and I can disable oldRoot.
This doesn't seem possible, if I understand your answers correct.
Is there another/better/default way of smoothly changing a trust anchor?
I.e. by cross-signing the newRoot by itself and the oldRoot?
Just add the new root-CA certificate to all relevant truststores. Afterwards
you can start issueing certificates that are trusted by all parties with
updated truststores.
HTH,
Patrick Eisenacher
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
RE: CRL default_crl_days
Hi Gregory, -Original Message- From: Gregory Sloop [snip] So, I thought - why should I set the default_crl_days to some low number. I assume that it [the CRL] can be replaced with a new CRL, should we need one, long before the default_crl_days limit is reached. Is that correct? Yes, this is correct. So, if that's the case, what would be the downside of making the default_crl_days equal to the validity of the CA itself, for example? [e.g. If the CA cert is valid for 100 years, why not set the default_crl_days to 36500+/- days too?] Every certificate that is revoked after the crl's issuance is naturally not contained in it. So a client querying a crl for a certificate's revocation status will falsely accept every certificate that was revoked after the crl's issuance. The longer your crl is valid, the more revoked certificates will slip through the check. Plus, the client has no need to update the crl as long as it is valid. This problem is inherent to crls. As such, you want to make your crls as short running as possible and usable in your environment. HTH, Patrick Eisenacher
RE: Free StartSSL certificate not trusted
-Original Message-
From Allan Nielsen
I have installed an ubuntu server with dovecot and a free certificate from
startssl, but I get:
verify error:num=20:unable to get local issuer certificate
and
verify error:num=21:unable to verify the first certificate
Any idea why?
[snip]
Certificate chain
0
s:/description=35l5njOWJKek82Eu/C=DK/CN=mail.minlilleverden.dk/emailAd
dress=postmas...@minlilleverden.dk
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
Signing/CN=StartCom Class 1 Primary Intermediate Server CA
---
Your server sends only an end entity certificate, whose issuer is not trusted
by your client. You need to add the issuer's certificate to your client's
truststore.
HTH,
Patrick Eisenacher
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
RE: OpenSSL Security Advisory
Hi Ted,
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
How do I determine whether or not the web servers I run are affected?
They are Apache 2.4, built for 64 bit Windows and downloaded from
Apachelounge. I have no idea what version of openssl it was built with. Does
anyone here know if the feature that introduces the risk can be turned off,
without introducing other risks? If so, how?
you can check for yourself:
- http://filippo.io/Heartbleed/
- http://possible.lv/tools/hb/
- https://github.com/noxxi/p5-scripts/blob/master/check-ssl-heartbleed.pl
Also, could the security keys we bought have been compromised?
Certainly yes. You should replace them. I read today that some CAs offer free
replacements.
HTH,
Patrick Eisenacher
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
RE: Certificate extensions
Peter, -Original Message- From: Peter Sylvester On 09/18/2013 09:53 AM, Eisenacher, Patrick wrote: -Please also note that adding extensions to a certificate request usually doesn't make any sense, as those get added to the certificate solely by the certificate issuer's grace. hi, I seem to disagree, well, usually saves you :-) Setting your email address or a server name into the subjectaltname, how do you do this otherwise? setting commonname for the server, ok, setting an email attribute that will them be copied by the CA (and the email removed because it is depracated)? Setting ALL extensions makes a lot of sense, IMO a CA should not add and modify thngs, a CA should *validate* them. The requester indicates what should be in the cert. The current practice by some registrars to add example.org as another name when you have ordered www.example.com etc may be nice for some people, but annoying for others, at best a surprise when policy and practice documents do not even mention these behaviours. you give valid exceptions, that's why I said usually. Those exceptions all serve to identiy the subject. It doesn't matter how these infos reach the CA, be it in-band or out-of-band. And it shouldn't matter how the request encodes that information in case the info is given in-band. The CA issues certificates conforming to a specific certificate profile. If the CA issues different types of certificates, it has a certificate profile for each type. The requestor can only choose between the types, ie. client or server cert, but not choose the structure of the certificate. Since a certificate is complex, PKI-knowledge is rare and the CA is liable for it, I don't think that letting your customers determine extensions or their criticality is a good idea. Furthermore, the CA's QA wouldn't be able to validate that their system works as expected and issues sound certificates that conform to PKIX or some other profile. Patrick Eisenacher
RE: multi-byte subject DN display
Hi binlu From: Bin Lu Re-post … as nobody responded. If I use “–nameopt utf8” option, the output of the subject is empty even for ascii string subject DN. This does not seem to match what is said in the man page. A bug? this works for me for subject DNames with UTF8String encoded RDNs: $ openssl x509 -subject -noout -nameopt esc_2253 -nameopt esc_ctrl -nameopt utf8 -nameopt dump_nostr -nameopt dump_unknown -nameopt dump_der -nameopt sname -nameopt sep_comma_plus -in cert_file HTH, Patrick Eisenacher
RE: OCSP and self signed
-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 contradiction so cannot hold.
- Root is not trusted, by elimination this must be true.
You have to communicate this fact out-of-band.
I never understood why some root-cas put a crldp extension into their
own certs.
this has sense in any cert except the root (self-signed) cert.
It makes sense for any non-broken client implementation.
Ideally, such roots keep an off-line copy of a pre-signed self-
revocation CRL, similar to the procedure used by experienced PGP
users (those who actually read the PGP 2.x manual). In case of
combined key compromise and loss, the off-line CRL is published,
thereby revoking the entire hierarchy.
The worst case disaster scenario is a large scale armed attack on the
center that keeps the private key. The attackers now have exclusive
control of the private key. But a far away trusted person can still
retrieve the self-destruction CRL and publish it through every means
imaginable, such as S/MIME e-mails (PEM style), sending it to software
update organisations (Microsoft, Mozilla, Apple, Google...) and for
all but one country, getting IANA/Internic assistance to force repoint
the DNS names of the CRL server to another server that serves up this
CRL and a message about the compromise.
The less worst case disaster scenario is an ordinary key compromise,
where the CA still has the private key and can sign a more precisely
dated revocation CRL and put the OCSP server in all is revoked mode.
Unfortunately, OpenSSL is broken and will apparently ignore all such
emergency messages.
Jakob, I don't understand your reasoning here.
You can't trust a signature of a compromised key. So if the root-ca's private
key gets compromised, you can't trust any of its issued crls and certificates
anymore. As such, pre-generating a crl for the case the root-ca doesn't have
access to its private key anymore doesn't seem to make sense. The root-ca's
only choice here is communicating this fact out of band to its customers, so
they can remove the compromised root-ca certificate from their truststores,
which is exactly what is happening today. The browser vendors even put it on an
internal blacklist, so re-adding it to the truststore won't have any effect. I
can't see where openssl is broken in this regard.
Patrick Eisenacher
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
RE: OCSP and self signed
-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 can't trust a signature of a compromised key. So if the root-ca's private key gets compromised, you can't trust any of its issued crls and certificates anymore. This is where your and OpenSSL's logic fails: If you receive a signed message from a CA saying it cannot be trusted, you have 3 ways to react: A) Just believe it and revoke the CA. B) Assume it cannot have been legitimately generated and must thus have been created by means of a compromised key, thus concluding that the CA can no longer be trusted. C) Ignore it and proceed as if you have not seen it, which is very, very stupid. Because A and B have the same effect and require the same code, they are equally good. C is just plain crazy. As such, pre-generating a crl for the case the root-ca doesn't have access to its private key anymore doesn't seem to make sense. The root-ca's only choice here is communicating this fact out of band to its customers, so they can remove the compromised root-ca certificate from their truststores, which is exactly what is happening today. The browser vendors even put it on an internal blacklist, so re-adding it to the truststore won't have any effect. I can't see where openssl is broken in this regard. All the recent out of band root revocations have involved revocation against the will of a no longer trustworthy CA. So the CA was not communicating remove our root, and the trust store distributors had to act out of band and take countermeasures in case the bad CA persisted in socially engineering people to add them back in local trust stores. My complaint is about situations where CA officials willingly revoke one of their roots. As I said before, there's no pki-inherent mechanism to revoke a self signed certificate other than to remove it from your truststore. This is the inverse step to giving the certificate trust by adding it to the truststore earlier. The root-ca needs to communicate this fact out of band to its customers, whether it wants to willingly withdraw the certificate or whether it was hacked and is forced to withdraw it doesn't matter here. This communication can be via phone call/snail mail/website announcement/signed mail by a still trusted certificate, i.e. belonging to a different pki/unsigned mail/whatever is stated in the ca's cps. Alternatively, the media can jump in and spread the news. In any case, such a situation always involves action on your side to adjust your trust settings, as there is no pki-automatism that can help you. Patrick Eisenacher
RE: OCSP and self signed
-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 one of their root cert. - these are
always self signed - uses a cert that comes from another root cert., or
this root cert itself to sign the CRL where it revokes the compromised
root cert;
doing so has a total different quality: the CA can't remove their
compromised root cert from the trusted cert store of your system, but
with the CRL they can tell your system, not to trust any cert that was
signed by the compromised root cert;
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.
Patrick Eisenacher
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
RE: OCSP and self signed
-Original Message- From: redpath I agree with this Once again, I would like to advocate that the openssl verification code should allow a self-signed certificate to revoke itself, using the same mechanisms as for revoking anything else. I was wondering how the root cert gets revoked. Anyway thanks for posting that request. A self-signed certificate can't be revoked via a crl, because you won't be able to successfully verify its signature. You have to communicate this fact out-of-band. I never understood why some root-cas put a crldp extension into their own certs. Patrick Eisenacher
RE: sslv3 alert bad certificate
From: Mithun Kumar Any pointers why below error is thrown by openssl? error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate:s3_pkt.c:1193:SSL alert number 42 Your peer didn't like your certificate and sent you a fatal bad certificate alert message. HTH, Patrick Eisenacher
RE: Why Openssl s_server is allowing Session Reuse on the same tcp connection
-Original Message- From: sajualways But what Use Case does this have, where client tells the server to resume the ssl session on the same tcp connection. The use case is changing the keys for securing long-standing connections. Of course this is in the server's responsibility, but the mechanism is the same for client and server. HTH, Patrick Eisenacher
RE: Why Openssl s_server is allowing Session Reuse on the same tcp connection
-Original Message- From: sajualways Openssl s_server is allowing Session Reuse on the same tcp connection Yes, of course. Why not? The ssl protocol is taking place on a higher OSI level than tcp, so it doesn't matter whether it's the same or a different tcp connection. When a second client hello is sent with session id of first handshake it is reusing i.e it is doing a session resumption instead it should do Renegotiation By sending an ssl session id, your client tells the server to resume that ssl session. If your client doesn't want to resume any ssl session, but start a new one and thus undergo a full handshake, then simply make it not send an ssl session id. HTH, Patrick Eisenacher
RE: handling of expired certificates
From: Salz, Rich OpenSSL does nothing about this. It’s an interesting question. As for as TLS/SSL is concerned, it is only using the certificate at the time the connection is initially established, and therefore expiration (or revocation) during the application’s use of the certificate is up to the application. The only practical use that I can imagine is using something in the cert (DN or an extension) for authorization decisions… If the application has the need to re-verify the certificate on SSL level, it can renegotiate the connection's SSL parameters. Alternatively, it can close down the current connection and establish a new one. Both ways cause a new handshake to be started. HTH, Patrick Eisenacher
RE: Use TLS over UDP connection
-Original Message- From: saurav barik Can I use TLS over a UDP connection(I understand DTLS can be used but my project needs TLS)? No, you can't. You need a reliable transport protocol, i.e. TCP. See RFC 5246. It's right there in the first paragraph of chapter one. Patrick Eisenacher
RE: Failed SSL/HTTP connections via Apache(2.4.3)SSL when going from 1.0.1c to 1.0.1e
-Original Message-
From: Dave Thompson
From: owner-openssl-us...@openssl.org On Behalf Of Joel Bion
Sent: Monday, 18 February, 2013 13:57
The issue I have been reporting has never been on the client
side, as the
problem is seen when connecting into a server that is booted into a
1.0.1e-environment vs. a 1.0.1c based environment. The two
environments
are pretty much identical. They are both LinuxFromScratch based
environments, where the core build (prior to
OpenSSL/HTTPD/MySQL install)
is identical, bit by bit, in both, and the primary difference
in the two
is to use OpenSSL 1.0.1c vs. OpenSSL 1.0.1e. So there is
minimal server
difference. OpenSSL 1.0.1c server can receive connections; the 1.0.1e
cannot. The 1.0.1e reports the error as shown, and closes the
connection -
as can be seen in that there is much more transferred from
the server in
the 1.0.1c case vs. the 1.0.1e.
What you show is what s_client reports *talking to* 1.0.1{e,c}.
We apparently need information from the server, see below.
Nevertheless, here is s_client -debug, snipped
That second -debug (to 1.0.1e) appears normal up to the point
client sends CKey,CCS,CFinished and expects STicket,SCCS,SFinished,
but instead receives EOF (read count 0 = normal disconnect).
Either the server process is dying and Unix is closing the socket
automatically (which shouldn't happen) or either OpenSSL or httpd
code is closing the socket when it shouldn't (unless possibly httpd
hits a time limit, but any such should be long enough you would have
noticed plus it shouldn't vary between OpenSSL versions).
After this is httpd still running, or did it die (and maybe restart,
depending on how you run it)? If it died, is there a corefile, or
if corefile is disabled (as often is on Linux) can you enable it?
Is there anything in the log, and if not (or incomplete) can you
set any option to increase logging (IMLimitedE httpd defaults to
being very reticent about logging)?
Additionally, try invoke s_client with the -trace and -state options to get
more human readable output. But as Dave has already pointed out, your client's
write to the socket fails, because the underlying connection was closed down
and you should enable maximum lovlevel in your server and check its logfile for
any hints.
HTH,
Patrick Eisenacher
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
RE: Failed SSL/HTTP connections via Apache(2.4.3)SSL when going from 1.0.1c to 1.0.1e
Hi Joel,
-Original Message-
From: Joel Bion
Here is the output from running an 'openssl s_client -debug' command (as
much verbosity as I could quickly find.) The key difference between the
two seems to be in the 1.0.1e case, there is this extra text at the end.
1.0.1c does not show this error.
Looks like your client doesn't trust the server's root CA certificate. Try to
invoke s_client with either the -CApath or the -CAfile option.
$ man s_client
is your friend.
HTH,
Patrick Eisenacher
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
problem with private extension definitions via oid_section
I'm troubled by what seems to be a weird problem with private oid definitions in ca.conf. Issuing a certificate works perfectly with the attached ca.conf file, as long as I specify the private extension via its OID in the [ my_ext ] section. When I replace the OID line with the commented out line above it to use the extension's name that was defined before in the [ new_oid ] section, I get the following error: Using configuration from /usr/local/etc/pki/ca.conf Error Loading extension section my_ext 140474292033192:error:0D06407A: asn1 encoding routines:a2d_ASN1_OBJECT:first num too large:a_object.c:109: 140474292033192:error:22074073:X509 V3 routines:V3_GENERIC_EXTENSION: extension name error:v3_conf.c:271:name=documentTypeList Am I doing something wrong or did I stumble over a bug? Why is the OID definition in the [ new oid ] section not being picked up? The command I use to issue the cert is: $ openssl ca \ -config ca.conf \ -batch \ -subj $SUBJECT_NAME \ -startdate $CERT_VALID_FROM \ -enddate $CERT_VALID_TO \ - in $REQUEST_FILE This is with openssl v1.0.0-beta3 on SLES11. Thanks for any insight, Patrick Eisenacher ca.conf Description: ca.conf
RE: [openssl-users] problem with private extension definitions via oid_section
Hi Erwann, -Original Message- From: Erwann Abalea oid_section = new_oids must be in the top level, not in [ca], [myca], or whatever. Just move that declaration to the top. Thank you. This works like a charm. Patrick Eisenacher
RE: OpenSSL version 1.0.1e released
-Original Message- From: OpenSSL The OpenSSL project team is pleased to announce the release of version 1.0.1e of our open source toolkit for SSL/TLS. This new OpenSSL version is a new feature release. For a complete list of changes, please see http://www.openssl.org/source/exp/CHANGES. Unfortunately, this link doesn't work.
RE: Passing TLS sessions between programs
-Original Message- From: Richard Könning Am 03.11.2012 15:26, schrieb Frediano Ziglio: Hi, I'm searching for a way to pass a TLS session between two programs under Unix. I can use unix sockets to send the file descriptor but I don't know how to request to OpenSSL crypto information (like algorithm used and key) in order to pass to the other process. Is there a way to do it ? Use http://www.openssl.org/docs/ssl/SSL_get_session.html as a starting point for reading. Once you have the SSL_SESSION, convert it to ASN1 (via i2d_SSL_SESSION) and dump it to a file. Read that file in with your second program and convert it back from ASN1 to SSL_SESSION(via d2i_SSL_SESSION) and add it to the SSL_SESSION cache of the SSL_CTX (via SSL_CTX_add_session). HTH, Patrick Eisenacher
RE: peer not authenticated
From: al so
openssl s_client -showcerts -connect TP.COM:443
CONNECTED(0003)
depth=1 /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International
Server CA - Class
3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
verify error:num=20:unable to get local issuer certificate
verify return:0
16747:error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad
certificate:s3_pkt.c:1093:SSL alert number 42
16747:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:188:
The error tells you that the server doesn't like your client cert chain. As
such, it sends a bad certificate alert. You should check the server's log for
any details.
HTH,
Patrick Eisenacher
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
RE: [openssl-users] How does openSSL handle the pathlen constraint?
-Original Message- From: Erwann Abalea Bonjour, Le 21/05/2012 14:10, Serge Emantayev a écrit : Hello openSSL gurus, I faced an issue of pathlen constraint checking by openSSL when verifying the client certificate. I did few studies for how openSSL does that and I appreciate your assistance on clarifying the issue. 1. The certificate chain with a pathlen constraint defined in a root CA: Root CA, pathlen:1 \ policy CA, pathlen:none \ issuer CA, pathlen:none \ client certificate In the first case openSSL does not verify the certificate correctly (i.e. the verification succeeds). It ignores the pathlen constraint defined in the root CA. This is conformant with X.509. The basicConstraints extension is not taken in consideration if present in a trust anchor (a root certificate is a trust anchor). Download X.509 recommendation, see chapter 10 (from memory), the validation algorithm is described. Actually, I find this hard to believe. The verifying party can deem any certificate as trusted and thereby making it its trust anchor. Nevertheless the verification process needs to take into account the extensions of the trust anchor and I don't see any reason to exclude basicConstraints. Can you please cite the relevant part of the validation algorithm that you reference? Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl-users] How does openSSL handle the pathlen constraint?
-Original Message- From: Erwann Abalea Le 22/05/2012 10:57, Eisenacher, Patrick a écrit : -Original Message- From: Erwann Abalea Bonjour, Le 21/05/2012 14:10, Serge Emantayev a écrit : Hello openSSL gurus, I faced an issue of pathlen constraint checking by openSSL when verifying the client certificate. I did few studies for how openSSL does that and I appreciate your assistance on clarifying the issue. 1. The certificate chain with a pathlen constraint defined in a root CA: Root CA, pathlen:1 \ policy CA, pathlen:none \ issuer CA, pathlen:none \ client certificate In the first case openSSL does not verify the certificate correctly (i.e. the verification succeeds). It ignores the pathlen constraint defined in the root CA. This is conformant with X.509. The basicConstraints extension is not taken in consideration if present in a trust anchor (a root certificate is a trust anchor). Download X.509 recommendation, see chapter 10 (from memory), the validation algorithm is described. Actually, I find this hard to believe. The verifying party can deem any certificate as trusted and thereby making it its trust anchor. Nevertheless the verification process needs to take into account the extensions of the trust anchor and I don't see any reason to exclude basicConstraints. Can you please cite the relevant part of the validation algorithm that you reference? Taken from X.509, 2008/11 edition. But IIRC, the algorithm is the same since the 2000 edition, at least. - 10.5 Certificate processing Each certificate is then processed in turn, starting with the certificate signed using the input trusted public key. The last certificate is considered to be the end certificate; any other certificates are considered to be intermediate certificates. - Note that the first certificate taken into consideration is signed by the trust anchor, and not the trust anchor itself. - 10.5.1 Basic certificate checks The following checks are applied to a certificate. Self-signed certificates, if encountered in the path, are ignored. a) Check that the signature verifies, that dates are valid, that the certificate subject and certificate issuer names chain correctly, and that the certificate has not been revoked. b) For an intermediate version 3 certificate, check that basicConstraints is present and that the cA component in the basicConstraints extension is TRUE. If the pathLenConstraint component is present, check that the current certification path does not violate that constraint (ignoring intermediate self-issued certificates) [...other basic steps...] - The same logic applies for other constraints extensions. Basically, from the trust anchor, you only take the public key, name, and validity dates. No extension at all. That's because a trust anchor doesn't need to be a certificate at all. Hi Erwann, I guess it's time to re-read in-depth the lengthy chapter on certification path validation of RFC 5280 and pay special attention to trust anchors in form of self signed and non-self signed certificates :o) Thanks for clarification, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: subjectAltName requirements
Hi Andy, -Original Message- From: Andy GOKTAS I'm generating a CSR and need to include subjectAltNames (about 6 of them). I remember reading (but I could be dreaming) a while back that you MUST include your CN in the subjectAltName list - and it should be listed first in the subjectaltname list, otherwise it won't work; or you will experience issues. Is this true? no, this is not true. I assume you're talking about a server certificate. The question you have to ask yourself is: Which clients/browsers do I want to support. And then you can check yourself how they behave if you don't add the hostname contained in the cn to the list of subjectAltNames. If I remember correctly, the last time I checked this, Opera required the cn's hostname additionally in a subjectAltName extension. But this is 6 years ago, and my memory could be at fault... HTH, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Re: Verify intermediate certificate
-Original Message- From: Steffen DETTMER * Johannes Bauer wrote on Fri, Jan 13, 2012 at 14:22 +0100: [...] Or, in other words: Let's assume I have a ultimate root (self-signed) Root and a branched CA X. I would like to trust X and all it's children, but not Root. Is this not possible? [yes, it is not possible by default] Thank you for your clarification. I also do not really see the point why the anchor of trust has to be self-signed. I also wondered about this time ago. I think when a user explicitely puts a sub-CA or even a non-CA certificate into the database of trusted certificates, chain verification could stop there without knowing the root-CA. If I remember correctly, there is work going on to enable such functionality in an upcoming release. Perhaps Steve can shed some light on its status. Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
ASN.1 encoding question
Hi guys,
I'm using asn1parse -genconf to der encode the following asn1 structure:
URLs ::= SEQUENCE OF {
url0 [0] EXPLICIT GeneralName [6] OPTIONAL,
url1 [1] EXPLICIT GeneralName [6] OPTIONAL,
url2 [2] EXPLICIT GeneralName [6] OPTIONAL
}
but I have a hard time to encode the GeneralName[6] part of it.
GeneralName ::= CHOICE {
otherName [0] OtherName,
rfc822Name [1] IA5String,
dNSName[2] IA5String,
x400Address[3] ORAddress,
directoryName [4] Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER
}
My genconf file looks like the following:
[ url ]
url0 = EXPLICIT:0,IA5STRING:http://www.host0.com/path0
url1 = EXPLICIT:1,IA5STRING:http://www.host1.com/path1
url2 = EXPLICIT:2,IA5STRING:http://www.host2.com/path2
[ URLs ]
URLs = SEQUENCE:url
But this of course only gives me the first explicit tag plus IA5String for
every url. How would I need to modify my genconf file to get the second tag
instead of ia5string?
Thanks for your help,
Patrick Eisenacher
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: ASN.1 encoding question
Ok, found the answer shortly after posting my message to the list. Here's the
answer for the archive:
-Original Message-
From: Eisenacher, Patrick
I'm using asn1parse -genconf to der encode the following asn1
structure:
URLs ::= SEQUENCE OF {
url0 [0] EXPLICIT GeneralName [6] OPTIONAL,
url1 [1] EXPLICIT GeneralName [6] OPTIONAL,
url2 [2] EXPLICIT GeneralName [6] OPTIONAL
}
[snip]
This would be the corresponding genconf file:
[ url ]
url0 = EXPLICIT:0,IMPLICIT:6,IA5STRING:http://www.host0.com/path0
url1 = EXPLICIT:1,IMPLICIT:6,IA5STRING:http://www.host1.com/path1
url2 = EXPLICIT:2,IMPLICIT:6,IA5STRING:http://www.host2.com/path2
[ URLs ]
URLs = SEQUENCE:url
Patrick Eisenacher
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Revocation with a renewed/rekeyed Root CA
Hi Erwann, -Original Message- From: Erwann Abalea Bonjour, While testing Apache-trunk (which will become apache 2.3.15), including the patch to use OpenSSL CRL validation, I've come to disagree with what OpenSSL does. My scheme is: - CA1 is a root (trust anchor), which is now in its first generation (lets call it CA1g1) - U1, U2, U3 are end-user certificates, issued by CA1 - U1 is revoked, and the CRL is published (lets call it CRLg1) you can't revoke a root CA by the means of a CRL. This works only out-of-band, i.e. you have to declare that the root CA in question is revoked and spread the news to all your customers. The problem here is that you can't trust a CRL when its signature key is compromised. The X.509 2008 edition category b) concept that you cite is new to me and according to my understanding of PKI this doesn't make sense, because there is no trust relationship between any self signed keys, so I can't trust that key 2 has any relationship to key 1, specially not to issue its CRLs. Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Possibility to create CRL without the CA key
Hi Villiam, -Original Message- From: Viliam Durina Sent: Monday, May 02, 2011 12:50 PM To: openssl-users Subject: Possibility to create CRL without the CA key Hello, I'm doing my own CA with openssl and want to regularly generate CRLs. We plan limited use of the CA (say 1-2 certificates per year), so the CA private key is stored in a safe on a USB stick until it is used next time. But, as far as I know, we will need it to generate CRL quite often. I see two possible solutions: 1. be able to sign the CRL with another key, signed with that CA: is this possible? 2. generate the CRL with very long validity (say 1 year) and regenerate a new one when needed: isn't this breaking some PKI rules or common practices? A CA can delegate the issuance of CRLs to a CRL issuer by issuing that instance a certifiate with the key usage cRLSign. You can read up the details on that in RFC5280, chapter CRL and CRL Extensions Profile. HTH Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: How I can find URI for this ca certificate?
Hi Akash, -Original Message- From: Akash Deo Sent: Monday, May 02, 2011 7:19 AM To: openssl-usersSubject: How I can find URI for this ca certificate? Hi, I am trying to verify whether a ca signed certificate is revoked. Openssl verify option requires following parameters: cert : A ca signed certificate to be verified. cafile: FilePath to ca certificate used to sign the certificate (cert). How I can find URI for this ca certificate? crlfile: Can be obtained from CRL Distribution Points field in certificate (cert). How I can find URI for ca certificate? Wherever you put the CA certificate on your filesystem, that's your cafile. How you retrieve the CA certificate, you have to figure out yourself. Usually CAs publish their CA certificates on their website and/or on their directory server. Also application protocols usually provide means for adding all the certificates necessary to verify a signature to said signature. HTH, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: [FWD] Intermediate certificate chain not included when exporting as pkcs12
-Original Message- From: Lutz Jaenicke Forwarded to openssl-users for discussion. Best regards, Lutz - Forwarded message from Alexander Mills - From: Alexander Mills Recently I was tasked with using a .crt and .key used in Apache for use with Apache Tomcat. I searched around and the solution was to use the following command, where the p7b file is the intermediate certificate provided by Thawte. openssl pkcs12 -export -in myCert.crt -inkey myKey.key -out mypkcs12.p12 -name tomcat -CAfile ssl_pkcs7.p7b -caname root -chain For some reason, which I am yet to fathom, the above command will not export the intermediate chain, and thus the certificate becomes untrustworthy. The following command works for me: $openssl pkcs12 -export -in cert.pem -inkey key.pem -name mylabel -chain -CAfile ca_path.pem -out archive.p12 -passout pass:mypassphrase ca_path.pem contains the concatenated CA certificates of cert.pem's certificate chain, encoded in PEM-format. So obviously what you pass in via -CAfile has the wrong format. Also make sure that all CA certificates of your chain are included in that file. HTH, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: ASN.1 encoding a private structure
-Original Message- From: Peter Sylvester On 02/14/2011 01:11 PM, Eisenacher, Patrick wrote: I want to encode a private asn1 structure, say something like the following: SEQUENCE true_false BOOLEAN certificate Certificate I checked the asn1parse command and was able to specify my outer sequence and the inner boolean in the genconf file, but failed to specify my certificate. I had hoped to specify the certificate via DER: 01 02 03... like I would with a private extension in openssl's conf file, but this didn't work. I also tried decoding the certificate via asn1parse and then re-encoding the output, but that didn't work neither. Is there any way to achieve my goal without manually constructing the asn.1 coding? Yes, you can/might - transform the certificate into an octet string in hex, - remove the initial tag and length, probably 4 octets, - specify an universal 16 implicit octet string and the content octets. the asn1parse encoder detect that the universal 16 is actually a sequence and will put automagically the constructed bit. Peter, you are my hero! This works like a charm :o) Thank you very much. Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
ASN.1 encoding a private structure
I want to encode a private asn1 structure, say something like the following: SEQUENCE true_false BOOLEAN certificate Certificate I checked the asn1parse command and was able to specify my outer sequence and the inner boolean in the genconf file, but failed to specify my certificate. I had hoped to specify the certificate via DER: 01 02 03... like I would with a private extension in openssl's conf file, but this didn't work. I also tried decoding the certificate via asn1parse and then re-encoding the output, but that didn't work neither. Is there any way to achieve my goal without manually constructing the asn.1 coding? Thanks for your help, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Adding non-root certificates to the list of trusted certificates?
-Original Message- From: Mounir IDRASSI Personally I don't think it is possible currently without a change to OpenSSL internals or the use of the verify callback. That being said, I remember vaguely a post by Dr Stephen Henson related to this where he mentioned a planned change in this direction, but I can't find a link to it. Yes, Mounir, you remember correctly. Matthias, search the archives for a thread named 'Terminate chain at intermediate certificate'. Stephan's post that Mounir cites, is from last year's 11th November. HTH, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: How to disable index and serial?
Hi Frederik, -Original Message- From: Fredrik Strömberg I want to sign a certificate without using the index or serial files. Can someone tell me how to disable them? you can't. But why would you care about openssl internals? Just generate your certificates and fine. Not using -config makes openssl use the compiled default, and using my own while commenting out database and serial gives me the error variable lookup failed for CA_default::database. If they can´t be disabled I would like to know if there´s a possibility to lock the files from openssl. Should that not work I need to implement my own filelocking. (For the curious: I don´t need serial because I only identify with CN, and I don´t need a database because I will never revoke any certificates.) Every certificate needs a serial, so you can't generate a certificate without a serial. Please also note that the subject name can't be used to identify a specific certificate, lest the subject name's CN RDN. For uniquely identifying a certain certificate you always need one of the couples (issuer, serial), (issuer, subject key identifier) or (issuer, subject - in case the CA's policy forbids the issuance of 2 cetificates for the same subject name). HTH, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Wrong cipher selected in handshake?
-Original Message- From: Victor Duchovni On Mon, Dec 06, 2010 at 11:36:01AM -0600, Mike Brennan wrote: It seems that Openssl doesn't always obey the server's priority s/doesn't always obey/never by default obeys/ ordered list of ciphers (set with SSL_set_cipher_list()), even when that list is syntactically correct, when the ciphers are available, and when the client capabilities don't constrain the choice. By default the server respects the client's priority. If you want the server to pre-empt the client's preference list, try: SSL_CTX_set_options(3) or SSL_set_options(3): SSL_OP_CIPHER_SERVER_PREFERENCE Apache also has an option for activating this: SSLHonorCipherOrder HTH, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Confusion about subject alternative names
Hi Gaiseric, -Original Message- From: Gaiseric Vandal I am using various version of openssl-0.9.x (including openssl-0.9.8k-1.fc11.i686 on my linux machine altho the cusotmized openssl.cnf file is probably inherited from a slightly earlier version.) When I create a certificate signing request with openssl, I have an option to specify an Subject Alternative Name (SAN.) The request file (csr) as well as the resulting certificate includes the SAN as a value in the in the subject field. Subject: C=US, ST=x, L=x, O=x, OU=IT, CN=server1.company.com/subjectAltName=server2.company.com/emailaddress=xx...@company.com I've never seen a subjectAlternativeName construction like this. This is not what openssl does by default. So this behaviour is related to the changes you did in your openssl.conf file. Looks like you defined your own private RDN subjectAltName. This is not standard. And nobody else will understand this! I recommend you read up about using the openssl req and ca commands, or alternatively the x509 command if you are using this to issue your certicates, and the format of the configuration file: man req man ca man x509 man config man x509v3_config HTH, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Fully UTF8 Subject line? UTF8 commonName?
Hi Lou, -Original Message- From: Lou Picciano Can someone point us to a hard example of encoding fields within a cert in UTF8? Specifically, we'd like to sign our CSRs with a UTF8-content 'subject' line. Essentially, we're ttying to be sure we spell our users' names correctly! this is how I do it: in your openssl.conf: [ req ] string_mask = utf8only utf8= yes your other settings and then in your code: openssl req -config /path/to/your/openssl.conf -subj your subject dname other options Then all fields of your subject dname except for the country rdn will be utf8-encoded. Country is always encoded as PrintableString. If you sign such a request in the ordinary way, you'll get a cert with an utf8-encoded dname. If you wanna change the subject of a csr before issuing a certificate for it via the -subj commandline option, you'll additionally need the two above mentioned settings in the ca-section of your openssl.conf. HTH, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl ca -subj and -utf8
Hi, I can make openssl's ca tool issue certificates with the subject's dname encoded as UTF8String for requests with UTF-8 encoded subject dnames. However, when I change the subject via the -subj commandline option, I can't seem to get a certificate with a UTF-8 encoded subject dname. Here's what I see: -subj is ascii string, no -utf8 commandline option - PrintableString -subj is ascii string, -utf8 commandline option - PrintableString -subj contains umlaut, no -utf8 commandline option - TeletexString -subj contains umlaut, -utf8 commandline option - TeletexString This is with openssl v1.0.0-beta3 15 Juli 2009. How can I make the ca tool encode the subject name given via the commandline as UTF8String? Thank you in advance, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: openssl ca -subj and -utf8
Hi Steve, -Original Message- From: Dr. Stephen Henson On Wed, Aug 11, 2010, Eisenacher, Patrick wrote: Hi, I can make openssl's ca tool issue certificates with the subject's dname encoded as UTF8String for requests with UTF-8 encoded subject dnames. However, when I change the subject via the -subj commandline option, I can't seem to get a certificate with a UTF-8 encoded subject dname. Here's what I see: -subj is ascii string, no -utf8 commandline option - PrintableString -subj is ascii string, -utf8 commandline option - PrintableString -subj contains umlaut, no -utf8 commandline option - TeletexString -subj contains umlaut, -utf8 commandline option - TeletexString This is with openssl v1.0.0-beta3 15 Juli 2009. How can I make the ca tool encode the subject name given via the commandline as UTF8String? Try adding a string_mask in the CA_default section of openssl.cnf and set it to utf8only. thank you so much, this works like a charm. Can you please add this to the documentation? And while we're at it, can you please also add the utf8 option to the documented list of configuration file options? They are both only documented for the req command. Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: 'No shared cipher error' connecting to OpenSSL server with Firefox using TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) cipher suite
Hi Alex, just check the list of ciphersuites that FF sends in its client hello message and you'll see which ciphersuites FF supports. HTH, Patrick Eisenacher -Original Message- From: Alex Birkett Hi, Firefox 3.6.2 supports the TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite. I've configured Open SSL (version 1.0.0.a) as a test server with what I think is a suitable ECC key/certificate (attached) The keys were created with the attached script. The server was started like this: openssl s_server -cert /home/alex/keys/ssltest/Certs/secp160r2TestServer.pem -cipher ECDHE-ECDSA-AES256-SHA An open ssl client can be successfully connected like this: openssl s_client -connect localhost:4433 The client says the connection is established with the ECDHE-ECDSA-AES256-SHA cipher When a connection with Firefox is attempted the server give a series of errors like this: 140068746417832:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1216: shutting down SSL Can anybody explain this? Could it be a bug in OpenSSL?
RE: 'No shared cipher error' connecting to OpenSSL server with Firefox using TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) cipher suite
Hi Alex, if you configure s_client with the same list of ciphersuites that firefox sends, then s_server will show the same reaction. That means your ff and your s_client send different lists of ciphersuites. You seem to invoke s_client with the standard list of ciphersuites...whatever that is. Try invoking s_client with -cipher ECDHE-ECDSA-AES256-SHA. Is the handshake still successful? Check the ciphersuite-id that s_client sends. Obviously it's different from those that ff sends. Now lookup the ciphersuite-ids in the specification and you see which ciphersuites ff and s_client indeed send. HTH, Patrick Eisenacher -Original Message- From: Alex Birkett Hi Patrick, Thanks for your response. FF 3.6.2 is sending TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA in it's client hello message. The command line OpenSSL client can be made to connect using this cipher suite. Any ideas? Thanks, Alex On 8 July 2010 13:41, Eisenacher, Patrick patrick.eisenac...@bdr.demailto:patrick.eisenac...@bdr.de wrote: Hi Alex, just check the list of ciphersuites that FF sends in its client hello message and you'll see which ciphersuites FF supports. HTH, Patrick Eisenacher -Original Message- From: Alex Birkett Hi, Firefox 3.6.2 supports the TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite. I've configured Open SSL (version 1.0.0.a) as a test server with what I think is a suitable ECC key/certificate (attached) The keys were created with the attached script. The server was started like this: openssl s_server -cert /home/alex/keys/ssltest/Certs/secp160r2TestServer.pem -cipher ECDHE-ECDSA-AES256-SHA An open ssl client can be successfully connected like this: openssl s_client -connect localhost:4433 The client says the connection is established with the ECDHE-ECDSA-AES256-SHA cipher When a connection with Firefox is attempted the server give a series of errors like this: 140068746417832:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1216: shutting down SSL Can anybody explain this? Could it be a bug in OpenSSL? -- Alex Birkett mBricks AS Fornebuveien 31, P.O. Box 69 NO-1324 Lysaker, NORWAY www.mbricks.nohttp://www.mbricks.no Follow us on Twitter: www.twitter.com/mBricksTeamhttp://www.twitter.com/mBricksTeam
RE: 'No shared cipher error' connecting to OpenSSL server with Firefox using TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) cipher suite
Hi Alex, are you sure, ff ist talking to the same server on port 4433? Do you get a successful handshake when using a different ciphersuite on the server? Patrick Eisenacher -Original Message- From: Alex Birkett Hi Patrick, openssl s_client -connect localhost:4433 -cipher ECDHE-ECDSA-AES256-SHA works fine it sends the following cipher suite in the client hello message: Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Just double checked with wireshark and FF also sends Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) as the first of of it's 35 supported cipher suites I started the serve like this openssl s_server -cert /home/alex/keys/ssltest/Certs/secp160r2TestServer.pem -cipher ECDHE-ECDSA-AES256-SHA -www so that it responds to the browser's http request. I tested this by sending a GET from the command line OpenSSL client and it works fine. Any other ideas? Thanks, Kind Regards, Alex On 8 July 2010 15:19, Eisenacher, Patrick patrick.eisenac...@bdr.demailto:patrick.eisenac...@bdr.de wrote: Hi Alex, if you configure s_client with the same list of ciphersuites that firefox sends, then s_server will show the same reaction. That means your ff and your s_client send different lists of ciphersuites. You seem to invoke s_client with the standard list of ciphersuites...whatever that is. Try invoking s_client with -cipher ECDHE-ECDSA-AES256-SHA. Is the handshake still successful? Check the ciphersuite-id that s_client sends. Obviously it's different from those that ff sends. Now lookup the ciphersuite-ids in the specification and you see which ciphersuites ff and s_client indeed send. HTH, Patrick Eisenacher -Original Message- From: Alex Birkett Hi Patrick, Thanks for your response. FF 3.6.2 is sending TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA in it's client hello message. The command line OpenSSL client can be made to connect using this cipher suite. Any ideas? Thanks, Alex On 8 July 2010 13:41, Eisenacher, Patrick patrick.eisenac...@bdr.demailto:patrick.eisenac...@bdr.de wrote: Hi Alex, just check the list of ciphersuites that FF sends in its client hello message and you'll see which ciphersuites FF supports. HTH, Patrick Eisenacher -Original Message- From: Alex Birkett Hi, Firefox 3.6.2 supports the TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite. I've configured Open SSL (version 1.0.0.a) as a test server with what I think is a suitable ECC key/certificate (attached) The keys were created with the attached script. The server was started like this: openssl s_server -cert /home/alex/keys/ssltest/Certs/secp160r2TestServer.pem -cipher ECDHE-ECDSA-AES256-SHA An open ssl client can be successfully connected like this: openssl s_client -connect localhost:4433 The client says the connection is established with the ECDHE-ECDSA-AES256-SHA cipher When a connection with Firefox is attempted the server give a series of errors like this: 140068746417832:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1216: shutting down SSL Can anybody explain this? Could it be a bug in OpenSSL? -- Alex Birkett mBricks AS Fornebuveien 31, P.O. Box 69 NO-1324 Lysaker, NORWAY www.mbricks.nohttp://www.mbricks.no Follow us on Twitter: www.twitter.com/mBricksTeamhttp://www.twitter.com/mBricksTeam -- Alex Birkett mBricks AS Fornebuveien 31, P.O. Box 69 NO-1324 Lysaker, NORWAY www.mbricks.nohttp://www.mbricks.no Follow us on Twitter: www.twitter.com/mBricksTeamhttp://www.twitter.com/mBricksTeam
RE: Adding OIDs
Hi Mag, -Original Message- From: Mag I'm interested in using custom OIDs for private application purposes. I've found the documentation to be deficient. For instance, in openssl.cnf it gives an example line of [ new_oids ] #testoid1=1.2.3.4 When I uncomment that line I can't even tell what the effect is; e.g., openssl req ... doesn't then prompt me for a testoid1 field. Just what is the effect of this supposed to be? That line only defines the label testoid1 and assigns the value 1.2.3.4. To use a private oid, you have to define its asn1 structure first. Afterwards you can include it in your request or certificate by referencing it in the appropriate config file section. If you defined a label, you can reference it by that name, otherwise you just use the dotted notation. Amongst my first questions is, when you add OIDs in this manner are you able to use the command line tool to supply values or does this require programmatic construction of certificates? (There's obviously the further question if yes of how the data is typed.) Yes, of course those defines are picked up by the commandline tools. For an example, check last month's archive for the thread Private Key Usage Period. HTH, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Adding OIDs
Hi Martin, -Original Message- From: Martin Kaiser Now I understand that the oid definitions in the config file are not just used internally (for defining extensions etc) but they're picked up by the command line tools. Is it correct that only req and ca use the oid definitions and others like x509 don't? I'd expect them to be picked up by every commandline tool that you can feed in a config file. Since x509 has no option for feeding in the config file, it doesn't know about the definitions you made there. As such, it can only give you the numerical representation, as you have already witnessed. A wild guess: Have you checked whether the -extfile option gets evaluated for displaying purposes as well? Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: on the security of wildcard certs (was: self-signed SSL certificates and trusted root certificate)
Hi Jeff, -Original Message- From: Jeffrey Walton Hi Patrick, I'm afraid I don't get your point. (1) Wild carding violates the Principle of Least Privilege. I can't see that any endpoint in the communication gets more privilege than necessary when I equip my host with a wildcard cert. In case your host is not only server, but also client and needs to authenticate itself against another server, then that's something else. You shouldn't equip a client with a wildcard cert and do strong authentication. But that wasn't the scenario we were talking about. (2) A certificate binds a public key to an entity such as a user or host. I claim using a wild card certificate to attest to all hosts in a domain violates the trust. In this case, why bother purchasing a wild card certificate from VeriSign or Comodo when you can say, We self-signed, Trust Us. In my minds, eye, both instill the same level of confidence. I beg to disagree. A public CA verifies the identity of the company, of the applicant, his relation to the company and that the company indeed own the claimed domain. Nothing of that is verified if you use a self signed certificate or play CA yourself. So you indeed have very different levels of confidence. Plus that's all the customer needs to know: The owner of the corresponding private key is indeed the owner of the domain in question. Trustwise, whether the host's name is a or b is of no relevance to the customer. All he wants to be sure of is that he is indeed talking to a host of the service provider that he intends to talk to. And a wildcard cert is giving him this trust. (3) Moxie's BlackHat presentation used the wild card feature to achieve his goals (see around slide 90 where he states, Get a domain-validated SSL wildcard cert...). But as said before, this is of no relevance here, because just because he is using a wildcard cert in his attack doesn't make deploying a wildcard cert on a server any less secure than a non-wildcard one, neither for the service provider, nor for the customer. As Rene has pointed already out, Moxie's presentation was about security weaknesses in browsers at the time of his talk or even earlier, not about security weaknesses in wildcard certs. So security-wise, I still can't see the major drawbacks you were talking about Apparently we have different security postures. So far you only claimed there is a security difference between wildcard and non-wildcard certs, but failed to demonstrate it. Renee and I gave you attack-scenarios that actually have the same security level and consequences in case of compromise when using wildcard and non-wildcard certs. Why don't you put your scenario on the table, so we can have a look at it? Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: self-signed SSL certificates and trusted root certificate
Hi Jeff, thanks for responding, but see my comments below. -Original Message- From: Jeffrey Walton Hi Patrick, can you please elaborate on where you see a security drawback in the attack scenario you mentioned when using wildcard certs over non-wildcard certs? Principle of leat privilege dictates that only a single server (or possibly related servers) be authenticated. However, a wild card will match all hosts(some hand waiving here) - even if the host was put in place by a bad guy. I'm aware of a couple of tools that will flag it. Exchange's Security Analyzer is one of them. As long as the bad guy doesn't compromise your private key, he won't be able to impersonate any of your hosts, wildcard cert or not. Once he compromises your key, he further needs to hack your dns to redirect traffic to his hosts. With a wildcard cert he can now add his hosts without interfering with the service of yours. Without a wildcard cert he would need to do add some logic to redirect traffic to your host whlie keeping others for himself. No big deal. But once your host is hacked, I guess it's much easier to compromise your app to his needs. No need to hack further into dns, to setup a server of his own and jump through more hoops, while increasing the chance of being detected. So security-wise, I still can't see the major drawbacks you were talking about earlier. I think wildcard certs are a valid option for securing your hosts. A related attack from Black Hat: http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/Bla ckHat-DC-09-Marlinspike-Defeating-SSL.pdf. But that presentation is talking about weaknesses in standard software and the way people are using them. Whether I protect my site with a wildcard or non-wildcard cert is of no relevance here. Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: self-signed SSL certificates and trusted root certificate
Hi Jeff, -Original Message- From: Jeffrey Walton As long as the bad guy doesn't compromise your private key, he won't be able to impersonate any of your hosts, wildcard cert or not. What happens in the case of a web farm behind a proxy or load balancer, where the forward facing host does SSL (perhaps through an accelerator)? well, off-loading ssl to dedicated host(s) infront of the application servers is hopefully the standard setup we are talking about. But I don't see how your question relates to the cited snippet. Are you saying, using a wildcard cert makes a difference over using n non-wildcard certs, when the attacker has access to the ssl terminator's keystore? Or are you thinking in the direction where the attacker manages to compromise a host behind the ssl termination? Again, every compromise is bad, but it doesn't matter whether the cert on the ssl terminator is a wildcard cert or not, does it? Jeff, I'm afraid I don't get your point. Can you please describe the attack scenario you're having in mind a bit more verbosely, where using a wildcard cert has indeed a security drawback over using a non-wildcard one? Thanks, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: self-signed SSL certificates and trusted root certificate
-Original Message- From: Eisenacher, Patrick Hi Jeff, -Original Message- From: Jeffrey Walton Hi Vieri, How does one issue a cert for multiple CN? Suppose I have just one HTTP server but it can be accessed via multiple FQDN... I suppose I need to use subjectAltName? Subject alternative name is one possibility. If you need a cert for several hosts/hostnames belonging to the same domain, a wildcard CN comes to mind as well, eg. *.domain.com. Wild carding usually makes the security folks cringe. A bad guy can stand up a malicious server, and the server appears legit to the outside world due to the wild card. can you please elaborate on where you see a security drawback in the attack scenario you mentioned when using wildcard certs over non-wildcard certs? Anybody else? Jeff's been MIA since a week and I still can't see why anybody would cringe... Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: self-signed SSL certificates and trusted root certificate
-Original Message- From: Vieri --- On Tue, 6/1/10, Dave Thompson wrote: CN doesn't need to be hostname or domainname for a CA cert. Technically not required on entity cert either, but on WWW most parties do want/like entity's CN to be domainname. How does one issue a cert for multiple CN? Suppose I have just one HTTP server but it can be accessed via multiple FQDN... I suppose I need to use subjectAltName? Subject alternative name is one possibility. If you need a cert for several hosts/hostnames belonging to the same domain, a wildcard CN comes to mind as well, eg. *.domain.com. HTH, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: self-signed SSL certificates and trusted root certificate
Hi Jeff, -Original Message- From: Jeffrey Walton Hi Vieri, How does one issue a cert for multiple CN? Suppose I have just one HTTP server but it can be accessed via multiple FQDN... I suppose I need to use subjectAltName? Subject alternative name is one possibility. If you need a cert for several hosts/hostnames belonging to the same domain, a wildcard CN comes to mind as well, eg. *.domain.com. Wild carding usually makes the security folks cringe. A bad guy can stand up a malicious server, and the server appears legit to the outside world due to the wild card. can you please elaborate on where you see a security drawback in the attack scenario you mentioned when using wildcard certs over non-wildcard certs? Thank you, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: How can I disable authentication?
Hi Dallas, -Original Message- From: Dallas Clement Just wondering what the best way to turn off authentication is. I'm wanting to do so for testing purposes. Would someone please advise? just configure aNULL (see ssl.h) for your ciphersuites on both endpoints. That way only ciphersuites without authentication get activated. HTH, Patrick __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Private Key Usage Period
Hi Bram, -Original Message- From: Bram Cymet I am wondering if with the latest version of Openssl it is possible to set the Private Key Usage Period extension and if so what is the format of the parameters? this is how I do it in my config file: [ ca_ext ] basicConstraints = critical, CA:true subjectKeyIdentifier = hash authorityKeyIdentifier = keyid keyUsage = critical, cRLSign, keyCertSign 2.5.29.16 = ASN1:SEQUENCE:privateKeyUsagePeriod [ privateKeyUsagePeriod ] notBefore = IMPLICIT:0,GENERALIZEDTIME:$ENV::PRIV_KEY_START notAfter = IMPLICIT:1,GENERALIZEDTIME:$ENV::PRIV_KEY_END Then my script sets PRIV_KEY_START and PRIV_KEY_END to their proper values in generalized time format and exports them before invoking the ca command. Works like a charm. HTH, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: CA.pl/CA.sh fail - can't create root CA
Hello asc123,
-Original Message-
From: owner-openssl-users On Behalf Of asc123
I'm getting a segv when trying to run CA.pl/.sh to create a rootCA:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
unknown option -create_serial
usage: ca args
-verbose- Talk alot while doing things
-config file- A config file
-name arg - The particular CA definition to use
-gencrl - Generate a new CRL
-crldays days - Days is when the next CRL is due
-crlhours hours - Hours is when the next CRL is due
-startdate YYMMDDHHMMSSZ - certificate validity notBefore
-enddate YYMMDDHHMMSSZ- certificate validity notAfter
(overrides -days)
-days arg - number of days to certify the certificate for
-md arg - md to use, one of md2, md5, sha or sha1
-policy arg - The CA 'policy' to support
-keyfile arg- private key file
-keyform arg- private key file format (PEM or ENGINE)
-key arg- key to decode the private key if it is encrypted
-cert file - The CA certificate
-in file- The input PEM encoded certificate request(s)
-out file - Where to put the output file(s)
-outdir dir - Where to put output certificates
-infiles - The last argument, requests to process
-spkac file - File contains DN and signed public key and
challenge
-ss_cert file - File contains a self signed cert to sign
-preserveDN - Don't re-order the DN
-noemailDN - Don't add the EMAIL field into
certificate' subject
-batch - Don't ask questions
-msie_hack - msie modifications to handle all those
universal strings
-revoke file- Revoke a certificate (given in file)
-subj arg - Use arg instead of request's subject
-extensions .. - Extension section (override value in config file)
-extfile file - Configuration file with X509v3 extentions to add
-crlexts .. - CRL extension section (override value in
config file)
-engine e - use engine e, possibly a hardware device.
-status serial - Shows certificate status given the serial number
-updatedb - Updates db for expired certificates
./CA.sh: line 197: 10495 Segmentation fault $CA
-create_serial -out
${CATOP}/$CACERT $CADAYS -batch -keyfile
${CATOP}/private/$CAKEY -selfsign
-extensions v3_ca -infiles ${CATOP}/$CAREQ
I tried removing the -create_serial option and then it
complains about the
-selfsign option. Removed that too - but it just errors out,
never creating
my root ca cert.
Any one encountered this before? Happens with openssl
0.9.8m/1.0.0 on suse
linux 9.
if you check the error message, you see that there is neither a -create_serial
option nor a -selfsign option, so I guess it's no surprise that openssl
complains. The absence of -selfsign is a bit weird, as this option is
definitely available in v0.9.8 and v1.0.0, but you've got more bugs in your
invocation. Also, try replacing your variables by their values and check the
content of your input files. Do you have a proper configuration file with all
the necessary content? Try referencing your configuration file via the -config
option. Add the -verbose option to get more output. As a starter you should
read about the usage of the various openssl command line tools
(http://www.openssl.org/docs/apps/openssl.html) or via man {tool-name} on your
system. The latter approach makes sure you get the documentation for your
installed version of openssl. The documentation also contains extensive
examples. Try starting with an example and then modify it according to your
needs.
HTH,
Patrick Eisenacehr
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Sign an SSL certificate with mutile trusted roots?
Hi Shaun, unfortunately that's not possible. To serve both groups of clients over https, you need to check the truststores of both clients for a common trust anchor and get a certificate for your server from exactly this ca. And make sure to get a certificate from exactly that ca, as the big public ca players have multiple cas in operation and the browsers come with pre-installed ca-certificates that are either non-operational anymore or not-yet-in-operation. In case the truststores don't have a common share, you need to set up two different hostnames. Perhaps you can do some redirection based on some identifying header information, but that would require your entry point to be a http-url. HTH and sorry for top-posting, Patrick Eisenacher -Original Message- From: Shaun Crampton I have a server that needs to serve content to two groups of clients over HTTPS. One group of clients are standard web browsers, with the normal group of trusted roots. The other group are embedded devices that only support certificates signed by the manufacturer's trusted root (which in not a standard browser trusted root). Is there any way to accomplish this while using only one domain? E.g. is it possible for me to send a CSR to Thawte, get back the certificate and then send it on to the embedded device manufacturer for an additional signature? Will browsers support it? Besuchen Sie die Bundesdruckerei auf der CeBIT 2010 vom 2.-6.3.2010, Halle 9, Stand D80 Visit Bundesdruckerei at CeBIT, exhibition centre, hall 9 / stand D80 weitere Informationen unter: http://www.bundesdruckerei.de/de/unternehmen/untern_cebit2010/index.html find more information here http://www.bundesdruckerei.de/en/company/comp_cebit2010/index.html __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: PKCS#7 extract and verify certificate?
Hi Patrick,
sorry for the bad line-breaking, but I'm stuck here with a poor msa.
-Original Message-
From: Patrick Patterson
On February 22, 2010 09:18:25 am Eisenacher, Patrick wrote:
-Original Message-
From: Patrick Patterson
On 12/02/10 8:51 AM, skillz...@gmail.com wrote:
Is there a way (via the API rather than the tool) to tell
OpenSSL that
the sub-CA certificate is trusted and it doesn't need to
walk further
up the chain? For my case, I embed the sub-CA
certificate in my code
and I'm space constrained so I'd prefer to not include
the entire
certificate chain.
According to RFC5280 this is not allowed (See section 6).
Given that if
the Root revokes the Sub-CA, the EE cert is invalid, you
have to check
the entire chain to ensure that all parts are still
valid. As a rule,
you can only use self-signed certificates as trust anchors.
This is not true. You only have to do path validation up to
your trust
anchor, whatever that is, be it a root-ca, an
subordinate-ca or even an ee.
Only if you check for revocation you have to walk up the
whole chain from
ee to root-ca.
According to RFC5280 (Section 6.1) - the following is the
basic requirement
for Path Validation:
The primary goal of path validation is to verify the binding between
a subject distinguished name or a subject alternative name and
subject public key, as represented in the target certificate, based
on the public key of the trust anchor. In most cases, the target
certificate will be an end entity certificate, but the target
certificate may be a CA certificate as long as the subject
public key
is to be used for a purpose other than verifying the signature on a
public key certificate. Verifying the binding between the name and
subject public key requires obtaining a sequence of
certificates that
support that binding. The procedure performed to obtain this
sequence of certificates is outside the scope of this
specification.
To meet this goal, the path validation process verifies, among other
things, that a prospective certification path (a sequence of n
certificates) satisfies the following conditions:
(a) for all x in {1, ..., n-1}, the subject of certificate x is
the issuer of certificate x+1;
(b) certificate 1 is issued by the trust anchor;
(c) certificate n is the certificate to be validated (i.e., the
target certificate); and
(d) for all x in {1, ..., n}, the certificate was valid at the
time in question.
If you DON'T use a self signed trust anchor, then you have to
have special
processing instructions, and/or have a certificate store that
is able to
absolutely treat a certificate differently when it is part of
a chain, or when
it is a trust anchor (for, and the reason why most Root CA
profiles don't have
CRL DP or OCSP info in them, a trust anchor is NOT checked
for validity - it
is assumed by its continued presence as a Trust Anchor to be valid).
The section you quote says absolutely nothing about self signed trust anchors.
This seems to be your own interpretation. Where did you get it from? If you
scroll just a few paragraphs further up you will see that a trust anchor can be
any entitiy in your PKI:
The selection of a trust anchor is a matter of policy: it could be
the top CA in a hierarchical PKI, the CA that issued the verifier's
own certificate(s), or any other CA in a network PKI.
And no, I don't need a separate truststore for subordinate-CAs. I have one
truststore into which I put those certs that I trust. I only have to build up
and verify a path up to a cert in my truststore. After all, a trust anchor is
just that: an anchor of trust. I don't need to verify further, when I trust
that entity.
Things get differently of course, if you do revocation checking, in which case
you always have to build up the whole path from ee to root-ca. But I stated
that before and we both agree on that.
Yes, it is probably a limitation to OpenSSL that it doesn't
really have a
Trust Anchor only store, but if you take a look at most major
implementations (US DoD, FBCA, CertiPath, SAFE, etc.) then
they pretty much
always use self signed root certs as the trust anchor.
openssl has a truststore. It just doesn't allow to trust subordinate-cas that I
intentionally put in there to be trusted. And that's what I consider a
limitation. And I don't understand what Eric's intention was when he originally
coded that algorithm. Of course, path construction and verification is a beast
to code and there are many pitfalls to fall into.
There are other sdks around that do not have this limitation. I worked for one
of their manufacturers long time ago.
Unfortunately, the perceived verification algorithm is a
limitation in
openssl, which always wants to do path validation up to a
self signed cert
RE: PKCS#7 extract and verify certificate?
-Original Message- From: Patrick Patterson On 12/02/10 8:51 AM, skillz...@gmail.com wrote: Is there a way (via the API rather than the tool) to tell OpenSSL that the sub-CA certificate is trusted and it doesn't need to walk further up the chain? For my case, I embed the sub-CA certificate in my code and I'm space constrained so I'd prefer to not include the entire certificate chain. According to RFC5280 this is not allowed (See section 6). Given that if the Root revokes the Sub-CA, the EE cert is invalid, you have to check the entire chain to ensure that all parts are still valid. As a rule, you can only use self-signed certificates as trust anchors. This is not true. You only have to do path validation up to your trust anchor, whatever that is, be it a root-ca, an subordinate-ca or even an ee. Only if you check for revocation you have to walk up the whole chain from ee to root-ca. Unfortunately, the perceived verification algorithm is a limitation in openssl, which always wants to do path validation up to a self signed cert, even if no revocation checking is requested. And no, there's no way to modify its verification algorithm besides from changing the code. This also has consequences for applications using openssl for ssl support like apache, where you can not easily configure to authenticate only those clients presenting a cert that was issued by a specific subordinate-ca. Patrick Eisenacher Besuchen Sie die Bundesdruckerei auf der CeBIT 2010 vom 2.-6.3.2010, Halle 9, Stand D80 Visit Bundesdruckerei at CeBIT, exhibition centre, hall 9 / stand D80 weitere Informationen unter: http://www.bundesdruckerei.de/de/unternehmen/untern_cebit2010/index.html find more information here http://www.bundesdruckerei.de/en/company/comp_cebit2010/index.html __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL renegotiation clarifications
Hi Saju, -Original Message- From: Saju Paul Who as in Sender-encrypter or Receiver-decrypter should renegotiate an SSL session? Can it be both or is it only the Sender? Is there a document that describes the protocol? Does renegotiation always require SSL handshake? (SSL_do_handshake) Are they any circumstances where the handshake is not necessary? SSL renegotiation described @ http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s03.html is a reference I'm planning to use and it suggest that the handshake is necessary. Need reconfirmation. --- Renegotiation is part of the SSL/TLS protocol and as such defined exactly there. Both client and server can initiate the renegotiation. And yes, renegotiation always triggers a new handshake. Please be aware that a security weakness was discovered lately in this renegotiation mechanism. A new TLS extension draft was published to close this weakneses. Currently, work is ongoing to adapt this extension in the relevant security tools. HTH, Patrick __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL renegotiation clarifications
Saju, forget about sender and receiver. Your communication endpoint, ie. client or server, issues a renegotiation on an SSL connection handle, just like it reads and writes to this SSL connection handle. Which logic you apply on when to issue your call to renegotiate is up to you and depends on your requirements. Usually you don't have the other communication endpoint under your control, so you should get clear about your side: Do you have to initiate renegotiation at all? If yes, when? And how do you react to a renegotiation request from the peer? HTH, Patrick Eisenacher -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Saju Paul Sent: Tuesday, February 02, 2010 4:24 PM To: openssl-users@openssl.org Subject: RE: SSL renegotiation clarifications Thank you Patrick. I'm aware that the SSL Client (SSL_connect) and SSL Server(SSL_accept) can renegotiate an SSL session. But my question is should the Sender(SSL_write) or the Receiver(SSL_read) do the renegotiation? For ex: if the Sender and Receiver decides to renegotiate either at a size(1G) or a time(2minute) boundary would it not result in two renegotiations at the boundary between the server and client. So even if either side can renegotiate; is there a preferred renegotiator? not sure if that is even a word but I hope you know where I'm going with this... Saju -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]on Behalf Of Eisenacher, Patrick Sent: Tuesday, February 02, 2010 9:07 AM To: 'openssl-users@openssl.org' Subject: RE: SSL renegotiation clarifications Hi Saju, -Original Message- From: Saju Paul Who as in Sender-encrypter or Receiver-decrypter should renegotiate an SSL session? Can it be both or is it only the Sender? Is there a document that describes the protocol? Does renegotiation always require SSL handshake? (SSL_do_handshake) Are they any circumstances where the handshake is not necessary? SSL renegotiation described @ http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s03.html is a reference I'm planning to use and it suggest that the handshake is necessary. Need reconfirmation. --- Renegotiation is part of the SSL/TLS protocol and as such defined exactly there. Both client and server can initiate the renegotiation. And yes, renegotiation always triggers a new handshake. Please be aware that a security weakness was discovered lately in this renegotiation mechanism. A new TLS extension draft was published to close this weakneses. Currently, work is ongoing to adapt this extension in the relevant security tools. HTH, Patrick __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Server won't request for client certificate
Hi Felipe, -Original Message- From: Felipe Franciosi [snip] SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT | SSL_VERIFY_ONCE, NULL); I believe my client is irrelevant at this point, because if I use openssl s_server, it works beautifully with my client. However, when I use my server and my client (or openssl s_client), it fails accusing my client of not providing the certificate. All points to my server not requesting the client certificate properly. You configured your server to stop the handshake if the client doesn't provide a certificate. And that's - according to the information you provide - exactly what you see. So all points to your client indeed: You have to find out why your client does not send the certificate that your server requests. If you use s_client with your server, I guess you'll see the certificate request message your server is sending. In that message the server tells the client which CAs and which certificates it accepts. So either your client's code is buggy (do you check for error conditions in your OpenSSL invocations? your snippet didn't seem to indicate so), it can't access its certificate, its certificate is not of the types requested by the server or its certificate is not issued by one of the CAs accepted by the server - as indicated in the above mentioned certificate request message. HTH, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RANDFILE in openssl.conf
Hi, specifying RANDFILE in openssl.conf within a section as per http://www.openssl.org/docs/apps/ca.html does not work. Instead, the randfile is created in the directory pointed to by the environment variable HOME. Only when I move the RANDFILE directive in front of the first section in openssl.conf, ie. as the very first statement, the directive is respected. If this is expected behaviour, the documentation should be fixed. Otherwise, this looks like a bug. My environment is openssl v0.9.8k on cygwin. Thanks, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Unable to load CRL
Hi Radhakrishna, -Original Message- From: owner-openssl-us...@openssl.org On Behalf Of Radha krishna Meduri -X (radmedur - HCL at Cisco) Hi Patrick We have one more update [r...@acsxp-srv3 radha]# [r...@acsxp-srv3 radha]# /opt/CSCOacsxp/.system/openssl crl -in abcd.crl -text unable to load CRL 13202:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:642:Expecting: X509 CRL [r...@acsxp-srv3 radha]# [r...@acsxp-srv3 radha]# /opt/CSCOacsxp/.system/openssl crl -inform DER -in abcd.crl -text | more Certificate Revocation List (CRL): Version 2 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: /C=US/DC=COM/DC=NWA/DC=PAD/O=Northwest Airlines Inc/OU=PAD/CN=Northwest Airlines PAD Low Assurance Issuing CA Last Update: Sep 30 04:54:00 2009 GMT removed lower part If you observe first command I did not mentioned -inform switch which failed to load but later command succeeded with that option. Why is it so? Because your CRL is DER-encoded, but you tell openssl that it is PEM-encoded (the default). Basically customer certificate was in DER format. Only the format of your CRL is of interest here. If CRL was in DER format, is it mandatory to mention -inform DER in the command line? That's what I wrote in my last mail. Please check again my answer and the documentation. Cheers, Patrick Eisenacher -Original Message- From: owner-openssl-us...@openssl.org On Behalf Of Radha krishna Meduri -X (radmedur - HCL at Cisco) Hi Patrick Eisenacher I converted this crl to PEM format which worked like charm. Is there any restriction like CRL's should be in PEM for mat only? Thanks Radhakrishna. -Original Message- From: owner-openssl-us...@openssl.org On Behalf Of Eisenacher, Patrick Hi Radhakrishna, -Original Message- From: owner-openssl-users On Behalf Of Radha krishna Meduri -X I am not able to load the crl in text format and I am getting following error while issuing following command openssl crl -in abcd.crl -text unable to load CRL 28950:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:642:Expecting: X509 CRL Any idea what could be issue? that means that abcd.crl has no proper PEM-encoding (base64 plus header and footer). The error messages states that openssl can't find the header. For more info about the header and footer, see http://www.openssl.org/docs/apps/crl.html#NOTES HTH, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Unable to load CRL
Hi Radhakrishna, -Original Message- From: owner-openssl-us...@openssl.org On Behalf Of Radhakrishna Meduri -X (radmedur - HCL at Cisco) Hi Patrick Eisenacher I converted this crl to PEM format which worked like charm. Is there any restriction like CRL's should be in PEM for mat only? nope, as always you can feed it in either PEM- or DER-encoded. PEM is openssl's default format. If your CRL is in DER-encoded (binary) format, you need to add -inform DER to openssl's crl command. Did you read the command options on the link below? HTH, Patrick Eisenacher -Original Message- From: owner-openssl-us...@openssl.org On Behalf Of Eisenacher, Patrick Hi Radhakrishna, -Original Message- From: owner-openssl-users On Behalf Of Radha krishna Meduri -X I am not able to load the crl in text format and I am getting following error while issuing following command openssl crl -in abcd.crl -text unable to load CRL 28950:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:642:Expecting: X509 CRL Any idea what could be issue? that means that abcd.crl has no proper PEM-encoding (base64 plus header and footer). The error messages states that openssl can't find the header. For more info about the header and footer, see http://www.openssl.org/docs/apps/crl.html#NOTES __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Unable to load CRL
Hi Radhakrishna, -Original Message- From: owner-openssl-users On Behalf Of Radha krishna Meduri -X Sent: Tuesday, December 08, 2009 12:29 PM To: openssl-users@openssl.org Subject: Unable to load CRL I am not able to load the crl in text format and I am getting following error while issuing following command openssl crl -in abcd.crl -text unable to load CRL 28950:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:642:Expecting: X509 CRL Any idea what could be issue? that means that abcd.crl has no proper PEM-encoding (base64 plus header and footer). The error messages states that openssl can't find the header. For more info about the header and footer, see http://www.openssl.org/docs/apps/crl.html#NOTES HTH, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: TLS trust of a chain of certificates up to a root CA. Certificate Sign extenstion not set
Hi Mourad, -Original Message- From: On Behalf Of Mourad Cherfaoui Sent: Wednesday, October 28, 2009 6:23 AM To: openssl-users@openssl.org Subject: TLS trust of a chain of certificates up to a root CA. Certificate Sign extenstion not set I have a chain of certificates C-B-A-RootCA. The TLS client only presents C during the TLS handshake. RootCA has the Certificate Sign extension set but not B and A. SSL requests the client to send all certificates necessary to verify its identity. Only when the client knows that the server has access to part of its certificate chain, it is allowed to send less. If you have control over the client, you should configure it to send its whole certificate chain. If you don't have control over the client, you need to add all certificates of the client's certificate chain that the client doesn't send to the server's truststore. This is your first requirement. Fix this first, then move on to the extension topic. The TLS server fails the TLS handshake because of the absence of the Certificate Sign extension in B and A. If the server can't build the client's certificate chain to a cert in its truststore, verification of the client's identity fails, and as such the handshake. My first question: if the TLS server has the entire chain of certificates B-A-RootCA in its truststore, is it correct to assume that the Certificate Sign extension is not required in B and A? No, your assumption is wrong. My second question: by default the TLS server will fail the TLS handshake because of the absence of the Certificate Sign extension. Is there a recommended way to disables the check for this extension in the TLS handshake? Once the server has constructed the client's certificate chain to one of its own trusted certificates, it starts verifying the certificate chain according to some verification profile. OpenSSL uses the PKIX profile has specified in RFC 5280. PKIX requires CA certificates to have the keyUsage extension and it should be marked critical. As such the extension needs to have at least the value keyCertSign. Check the RFC for more info about the keyUsage extension. 4 options come to mind how to solve your problem: - fix your configuration your certificates. This is the recommended way. - use X.509v1 certificates - they don't contain extensions - don't use SSL with client authentication, but then your client will probably fail to verify the server's identity as well, if the server is certified by a CA whose certificate is missing the keyUsage extension. - configure the server to move on with the handshake even in the case of a failed verification of the client's identity, i.e. request client authentication but grant access to anonymous clients as well HTH, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Certificate verification failed, error 7 (certificate signature failure) depth 2
I'm currently trying to integrate wpa_supplicant and OpenSSL 0.9.8k to authenticate to a wireless network using EAP-TLS. It seems like I'm failing on verifying the server certificate. Can anybody interpret the error for me error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm This is the relevant line, meaning your server certificate uses a digest algorithm that the openssl version you're using doesn't know. So try to figure out what digest algorithm was used in the software that created the server certificate, and if it is one that openssl doesn't support, change it to one that is supported. In case openssl lists the digest algorithm used as supported, that would hint at an encoding error of its object id on the creating software's side - or a decoding error on the openssl side. HTH, Patrick __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
privateKeyUsagePeriod x509v3 extension
Hi list members, is there a possibility to specify the x509v3 extension privateKeyUsagePeriod in the openssl.conf file for the req and ca commands? It seems, openssl knows the oid and asn1 structure of the extension but doesn't allow you to put it into certificates. When I specify privateKeyUsagePeriod = 365 or privateKeyUsagePeriod = notBefore:timestamp1,notAfter:timestamp2 in my extension setting for the req command, req complains 17054:error:22097067:X509 V3 routines:DO_EXT_NCONF:extension setting not supported:v3_conf.c:163:name=privateKeyUsagePeriod I worked around the problem by specifying the extension in its arbitrary extension format: [ req ] x509_extensions = req_ext [ req_ext ] 2.5.29.16 = ASN1:SEQUENCE:privateKeyUsagePeriod [ privateKeyUsagePeriod ] notBefore = EXPLICIT:0,GENERALIZEDTIME:timestamp1 notAfter = EXPLICIT:1,GENERALIZEDTIME:timestamp2 which puts the extension into the certificate request, but is not really handy for a configuration file, because you have to explicitly give the two timestamps. So in case the arbitrary extension format is the only way of getting the privateKeyUsagePeriod extension into the certificate, is there a way to specify parameterized values for the timestamps in openssl.conf, e.g. via the backtick operator and the date command? Or would I have to wrap the openssl command into my own script that modifies the timestamps in openssl.conf appropriately in advance? I'm using OpenSSL 0.9.8k 25 Mar 2009. Thanks for your help, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
