OpenSSL kerbose support
Hi, I'm working with openwsman to manage Windows server. OpenWSMAN uses OpenSSL (on linux based platforms) to authenticate the server; now Windows does not support digest and as per my understanding OpenSSL does not support Kerbos/GSSAPI. Please correct me if my understanding is wrong. Incase it is correct, does anyone know a timeframe to get that support in OpenSSL? Thanks! Ata
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
On 03/11/2013 11:17 PM, kap...@mizera.cz wrote: That is what we talk about here. Try to check previous posts in this thread. rfc 3126 tells This document mandates the presence of this attribute as a signed CMS attribute, and the sequence must not be empty. The certificate used to verify the signature must be identified in the sequence, the Signature Validation Policy may mandate other certificate references to be present, that may include all the certificates up to the point of trust. The encoding of the ESSCertID for this certificate must include the issuerSerial field. RFC 5035 says If more than one certificate is present, subsequent certificates limit the set of certificates that are used during validation. Certificates can be either attribute certificates (limiting authorizations) or public key certificates (limiting path validation). The issuerSerial field (in the ESSCertIDv2 structure) SHOULD be present for these certificates, unless the client who is validating the signature is expected to have easy access to all the certificates required for validation. If only the signing certificate is present in the sequence, there are no restrictions on the set of certificates used in validating the signature. The time stamp does not include issuerSerial in the second esscertid. There is no specification of any profile of time stamps that indicates that a client MUST support attribute certs. I do not think that the authors of 3161, 3126 has in mind any support of attribute certs. I don't recall any profile requiring this. if a timestamp ess would be ok with an attribute cert, what is the client supposed to do? It can verify the signatures of the attribute cert up to some trust anchor, but then? what authorisation is supposed to be checked? that the tsa is allowed to issue certs for a particular policy? (don't yes, maybe). if the TSKlient is able to do something non stadardized special verification, use that one. Peter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
SSL_VERIFY_PEER
Just wondering - if SSL_VERIFY_PEER is set on a connection, if the verification locations have not been loaded (SSL_CTX_load_verify_locations has not been set) - does the connection fail? Or continue as unverified? Also, is it possible to set the verify_location as somewhere remote (i.e. some URL) rather than some local path. Thanks __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
On 03/12/2013 09:30 AM, kap...@mizera.cz wrote: RFC 3161 is written badly. The whole text was a joke anyway. The requester SHALL verify that the TimeStampToken contains the correct certificate identifier of the TSA One may conclude that openssl should simply not validate anything else than the first certificate. And simply ignore the rest of the ESS sequence. Probably with an option. It must not be there, if the attribute cert is available. If the TSQ is with -cert = the TAC certificate is included in TSR. (I know - it is not in our example which is nocert). Is there anywhere in the policy of the TSA an indication about what a client is supposed to do with the atribute certificate, i.e. where is the documentation of the behaviour of their own client. There are two OID as attributes. . That is what about I fight with the Certification Authority. I was (I am) afraid if their timestamps are rfc 3161 compliant or not. They claim YES. What do you thing ? You can add critical extensions into the signing cert, whatever you want, you remain conformant but not interoperable. I'm not sure - on one side you are right: authors of 3161, 3126 has in mind any support of attribute certs but on the other side: rfc 3161 simply refers to RFC 2634 where are attr. certs mentioned = they may (can) be there and should not preclude verification process = the client MUST be able understand all what is in tree with 3161 as root. That's because the authors of RFC 3161 had probably overlooked the possibility of attribute certs. T he only reason for using ESSCert was to include a reference to the signing cert (and maybe its chain), but not to allow all options. Although the text says (last sentence): If the certReq field is present and set to true, the TSA's public key certificate that is referenced by the ESSCertID identifier inside a SigningCertificate attribute in the response MUST be provided by the TSA in the certificates field from the SignedData structure in that response. That field may also contain other certificates. I do not think that the last sentence means attribute certificates. In fact RFC 3161 doesn't tell what one has to verify, And, as said in the beginning, there is nothing in the text that says that a client has to verify anything beyong the TSA's signature cert. However, the actual identification of the entity that signed the response will always occur through the use of the certificate identifier (ESSCertID Attribute) inside a SigningCertificate attribute which is part of the signerInfo (See Section 5 of [ESS]). Here one talks about IDENTIFICATION, attribute certs are for something else. BTW: rfc 3126, 5035, ... are not referred by 3161 = in timestamps may be used only and only what is in tree with 3161 as root. = rfc 3126, 5035 are not valid for timestamps. if a timestamp ess would be ok with an attribute cert, what is the client supposed to do? It can verify the signatures of the attribute cert up to some trust anchor, but then? what authorisation is supposed to be checked? that the tsa is allowed to issue certs for a particular policy? (don't yes, maybe). if the TSKlient is able to do something non stadardized special verification, use that one. That is no solution - the Q is: are or are not these timestamps compliant with RFC 3161. Compliant is not the right word, conformant. And since there are no real conformance requirements, the question is almost useless. You may try to use the argument, that the TSA MUST include teh TSA cert into the ESScertid and add and nothing else but that won't word because this argument is French. ;-) The ESS cert that there SHOULD be a issuer and serial. That's not the case. If not, then they have no value. Remark: discussed CA (TSA) is official, one of main CA in our country - whole government things, law (electronic sigs, timestamps, ..), ... depends on such institution. So it is very important Q. The question is interoperability. As said, I think the openssl tests can simply be weakend to only validate the first ESS cert. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
Dne 12.3.2013 11:54, Peter Sylvester napsal(a): On 03/12/2013 09:30 AM, kap...@mizera.cz wrote: RFC 3161 is written badly. The whole text was a joke anyway. The requester SHALL verify that the TimeStampToken contains the correct certificate identifier of the TSA One may conclude that openssl should simply not validate anything else than the first certificate. And simply ignore the rest of the ESS sequence. Probably with an option. That is similar what I wrote about meantime solution until OpenSSL supports attr,certs. It must not be there, if the attribute cert is available. If the TSQ is with -cert = the TAC certificate is included in TSR. (I know - it is not in our example which is nocert). Is there anywhere in the policy of the TSA an indication about what a client is supposed to do with the atribute certificate, i.e. where is the documentation of the behaviour of their own client. There are two OID as attributes. . No. http://www.postsignum.cz/politiky_tsa.html That is what about I fight with the Certification Authority. I was (I am) afraid if their timestamps are rfc 3161 compliant or not. They claim YES. What do you thing ? You can add critical extensions into the signing cert, whatever you want, you remain conformant but not interoperable. I'm not sure - on one side you are right: authors of 3161, 3126 has in mind any support of attribute certs but on the other side: rfc 3161 simply refers to RFC 2634 where are attr. certs mentioned = they may (can) be there and should not preclude verification process = the client MUST be able understand all what is in tree with 3161 as root. That's because the authors of RFC 3161 had probably overlooked the possibility of attribute certs. T he only reason for using ESSCert was to include a reference to the signing cert (and maybe its chain), but not to allow all options. Although the text says (last sentence): If the certReq field is present and set to true, the TSA's public key certificate that is referenced by the ESSCertID identifier inside a SigningCertificate attribute in the response MUST be provided by the TSA in the certificates field from the SignedData structure in that response. That field may also contain other certificates. I do not think that the last sentence means attribute certificates. In fact RFC 3161 doesn't tell what one has to verify, And, as said in the beginning, there is nothing in the text that says that a client has to verify anything beyong the TSA's signature cert. No. It is defined here: RFC2634 page 47 The verification and possible usage of attr.certs is covered by other RFC which are referred in 3161 = 3161 must not say it - there are other RFCs an openssl have to support it to be usable for verifying not just TS, but all signed messages (rfcs about CMS, ESS, ...) which can contain attr. certs. However, the actual identification of the entity that signed the response will always occur through the use of the certificate identifier (ESSCertID Attribute) inside a SigningCertificate attribute which is part of the signerInfo (See Section 5 of [ESS]). Here one talks about IDENTIFICATION, attribute certs are for something else. ??? No - it has nothing to do with our problem BTW: rfc 3126, 5035, ... are not referred by 3161 = in timestamps may be used only and only what is in tree with 3161 as root. = rfc 3126, 5035 are not valid for timestamps. if a timestamp ess would be ok with an attribute cert, what is the client supposed to do? It can verify the signatures of the attribute cert up to some trust anchor, but then? what authorisation is supposed to be checked? that the tsa is allowed to issue certs for a particular policy? (don't yes, maybe). if the TSKlient is able to do something non stadardized special verification, use that one. That is no solution - the Q is: are or are not these timestamps compliant with RFC 3161. Compliant is not the right word, conformant. And since there are no real conformance requirements, the question is almost useless. You may try to use the argument, that the TSA MUST include teh TSA cert into the ESScertid and add and nothing else but that won't word because this argument is French. ;-) The ESS cert that there SHOULD be a issuer and serial. That's not the case. Why do you thing ? Where is it wrote ? And even if - it is SHOULD not MUST. The TAC is included - (if -cert in TSQ) - the HASH is enough - openssl has all it needs. It can chech the hash with hashes in included certs in TSR. If not, then they have no value. Remark: discussed CA (TSA) is official, one of main CA in our country - whole government things, law (electronic sigs, timestamps, ..), ... depends on such institution. So it is very important Q. The question is interoperability. As said, I think the openssl tests can simply be weakend to only validate the first ESS cert. No. Such solution would broke the norm - see
Re: SSL_VERIFY_PEER
On Tue, Mar 12, 2013 at 10:23:20AM +, Nathan Smyth wrote: Just wondering - if SSL_VERIFY_PEER is set on a connection, if the verification locations have not been loaded (SSL_CTX_load_verify_locations has not been set) - does the connection fail? Or continue as unverified? This is answered in some detail in: https://www.openssl.org/docs/ssl/SSL_CTX_set_verify.html if you find part of the answer confusing, it is best to ask a more specific question referencing the text in question. Also, is it possible to set the verify_location as somewhere remote (i.e. some URL) rather than some local path. https://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html so you mount a FUSE filesystem that provides secure access to remote URLs you could use that if you're sufficiently motivated (misguided?). -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: create certificate chain
Hi Dirk , Thanks for the reply . These commands worked for me . I have created a single key and and used it for ca-cert ,intermediate-cert and server/client cert . otherwise ,we can use separate keys and commands are like this : openssl genrsa -des3 -out ca.key 1024 openssl req -new -x509 -days 3650 -key ca.key -out ca.crt openssl x509 -in ca.crt -out ca.pem openssl genrsa -des3 -out ca-int_encrypted.key 1024 openssl rsa -in ca-int_encrypted.key -out ca-int.key openssl req -new -key ca-int.key -out ca-int.csr -subj /CN=ca-...@acme.com openssl x509 -req -days 3650 -in ca-int.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out ca-int.crt openssl genrsa -des3 -out server_encrypted.key 1024 openssl rsa -in server_encrypted.key -out server.key openssl req -new -key server.key -out server.csr -subj /CN=ser...@acme.com openssl x509 -req -days 3650 -in server.csr -CA ca-int.crt -CAkey ca-int.key -set_serial 01 -out server.crt -- View this message in context: http://openssl.6102.n7.nabble.com/create-certificate-chain-tp44046p44215.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: check certificate chain in a pem file
I have stored chain in trusted store and verified the leaf certificate . I have also done the similar with storing certificate chain except leaf certificate in untrusted store ,but here i had added exception in x_509 verify function to avoid th error of self signed root certificate stored in untrusted store. -- View this message in context: http://openssl.6102.n7.nabble.com/check-certificate-chain-in-a-pem-file-tp43871p44216.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL Crash at ssl_cert_free when closing TLS connection
Hi , I am facing problem while closing TLS connection and its not easy to reproduce or dont know how to reproduce it . is it know issue ? or what may be reason for this crash .I am using openssl 0.9.8 Crash Info : 0x10013118 create_crash_dump+7128 0x10011f2c create_crash_dump+2540 0x10007cfc sigsegv_handler+6168 0x3f0fee10 license_xos_thread_create+755850480 0x11de49c4 CRYPTO_add_lock+164 0x11e3a508 ASN1_primitive_free+1000 0x11e3a7f8 ASN1_item_free+48 0x11dd26c8 ssl_cert_free+272 0x11dd0830 SSL_free+456 Thanks Ashish -- View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-Crash-at-ssl-cert-free-when-closing-TLS-connection-tp44217.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
Hello, I found the following: http://tsa.postsignum.cz:444 produces the following error, when using this as time stamp server with adobe standard/pro BER decoding error what software do they use? my solution with OpenSSL works ... Greetings, Walter smime.p7s Description: S/MIME Cryptographic Signature
Re: [openssl-users] Re: possible Bug in OpenSSL - rfc 3161 - TSA service
You should have received an HTTP 400 error, with an HTML page. The service behind it may not be RFC3161 compliant, it may even not be advertised as RFC3161 compliant. Your solution works, but it doesn't answer the problem. -- Erwann ABALEA - québésectophile: séparatiste québécois Le 12/03/2013 20:36, Walter H. a écrit : Hello, I found the following: http://tsa.postsignum.cz:444 produces the following error, when using this as time stamp server with adobe standard/pro BER decoding error what software do they use? my solution with OpenSSL works ... Greetings, Walter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
Dne 12.3.2013 20:36, Walter H. napsal(a): Hello, I found the following: http://tsa.postsignum.cz:444 do you have account by this TSA ? produces the following error, when using this as time stamp server with adobe standard/pro BER decoding error Are you sure you (adobe program) get timestamp and not just HTML error page ? Try to get TSReply manually with CURL: openssl ts -query -data file.txt -sha256 -cert -no_nonce file.txt-nononce-sha256-cert.tsq curl -k -v -H Content-Type: application/timestamp-query -u name:password --data-binary @file.txt-nononce- sha256-cert.tsq https://tsa.postsignum.cz:444 file.txt-nononce-sha256-cert.postsignum.tsr what software do they use? my solution with OpenSSL works ... what do you mean with my solution with OpenSSL works ? That you use own testing, opennsl based TS server ? If yes and only timestamps from tsa.postsignum.cz:444 server cause this problem then it would be interesting, because the CA (TS Authority) claims that only openssl client has problem with their timestamps. Adobe client no. --kapetr __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
