Re: serverFull and otherFull
Thanks for response. Regarding those even i am not able to figure out what they are but recently i came across those term. When ever i get a clarity over it i will get back to you. Thank you. On Tue, Apr 22, 2014 at 10:31 PM, Wim Lewis w...@omnigroup.com wrote: On 21 Apr 2014, at 10:27 PM, Sri Ramya wrote: can any one explain me what is server full and theotherfull in openssl terminology??? I think we need more context. Where are you seeing those terms? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
SSL Root CA and Intermediate CA Certs.
Hi, I am new to SSL/TLS Certificates. Please help me understand what is the difference between ROOT CA Certs and Intermediate Certs or Chain Certs. I will appreciate if i can refer to some books or tutorials to know about SSL/TLS technology. Thanks and Regards, Kaushal
Re: SSL Root CA and Intermediate CA Certs.
On 23 Apr 2014, at 2:23 PM, Kaushal Shriyan kaushalshri...@gmail.com wrote: I am new to SSL/TLS Certificates. Please help me understand what is the difference between ROOT CA Certs and Intermediate Certs or Chain Certs. I will appreciate if i can refer to some books or tutorials to know about SSL/TLS technology. The closest thing you'll probably encounter in the real world to a digital certificate is a diploma or degree from an educational institution. Anyone can write John Smith (PhD) on a piece of paper, that doesn't indicate anything special or prove anything. We might improve that by writing John Smith (PhD), Faculty of Philosophy on that piece of paper, but again, which faculty of philosophy? Never heard of them. Still, the piece of paper is useless. We can however write John Smith (PhD), Faculty of Philosophy, University of Cambridge on the piece of paper and sign the paper by putting a great big seal on the paper to make the paper hard to forge. In theory, we have heard of and trust the University of Cambridge, and in turn the University of Cambridge trusts the Faculty of Philosophy, which in turn trusts John Smith. If we trust the University of Cambridge, then we trust John Smith. If we were using digital certificates instead of a certificate you might hang on a wall we might create a certificate called cn=John Smith (PhD) and get John Smith to sign it. This cert is largely meaningless, given that in order to trust John Smith we need to already trust John Smith using some out-of-band method. This is a self signed certificate. If we were using certificates with a full certificate authority, we would instead have a certificate called cn=John Smith (PhD) issued by and signed by ou=Faculty of Philosophy which is in turn issued by and signed by o=University of Cambridge. The o=University of Cambridge certificate is called the ROOT CA certificate, because we have manually trusted that one using an out of band method (we might have got it built into our browser). The intermediate certificate is the ou=Faculty of Philosophy certificate, which is trusted by o=University of Cambridge and trusts cn=John Smith (PhD). John Smith is the leaf certificate trusted by the others. All you need to do is trust the root CA certificate o=University of Cambridge, and you automatically trust everyone they trust, including cn=John Smith (PhD). Instead of relying on a big elaborate piece of paper with a wax seal on it, you rely on a mathematical equation that verifies that the certificate is legitimate, but the idea is the same. Regards, Graham -- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: ASN1_bn_print
From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Jeffrey Walton Sent: Sunday, 20 April, 2014 04:42 RSA_print_fp eventually calls ASN1_bn_print (multiple times) with each of the RSA parameters. ASN1_bn_print is shown below. A couple of questions: (1) why is the buffer 'buf' required for the function? Because a big number may be too big to fit in the built-in buffer. What is its size supposed to be? (I know 'BN_num_bytes(num)' is too small from a seg fault, but I don't know how large it needs to be). Big enough. No one has ever claimed the OpenSSL APIs are friendly. If you look at the code below, you'll see that it iterates through buf from 0 or 1 (because it may have incremented the buf pointer - per usual, this code is not designed for readability, despite the fact that readability is *critical* for reducing error rates in software) to n-1. n is either the return value from BN_bn2bin, or that value plus 1. Thus the maximum number of bytes used is the return value from BN_bn2bin plus 1. A quick look at BN_bn2bin shows that its return value is the return value of BN_num_bytes. That is actually a macro (defined in bn.h), but I think that answers your question. (2) why is a non-empty string required for 'number'? Are you asking why does the code behave as it does, or why is it designed to require a non-empty string? As for the former: (If 'number' is NULL, then the function seg faults. On your platform, perhaps. The code below clearly passes number to one of the printf family of C library functions, where it is used as the argument corresponding to a %s format specifier. Passing a null pointer as the argument for a %s format specifier invokes Undefined Behavior; the implementation is allowed to do anything. Some will helpfully print something like [null] or treat it as an empty string. Others will trigger a failure mode. Some may produce nasal demons. If 'number' is or empty, then the function fails. That seems unlikely, given the code, but I haven't bothered testing it. As to the latter question (why was the code designed that way): The OpenSSL APIs are not your friend. They aren't designed to be helpful, but to do whatever specific things need to be done for the functions OpenSSL provides. It's not how I would have designed them, but I haven't written an SSL/TLS implementation, and the OpenSSL developers have, so that's hardly a compelling critique. They do the work; they get to make the decisions. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com
Re: SSL Root CA and Intermediate CA Certs.
Hi, I am new to SSL/TLS Certificates. Please help me understand what is the difference between ROOT CA Certs and Intermediate Certs or Chain Certs. I will appreciate if i can refer to some books or tutorials to know about SSL/TLS technology. The closest thing you'll probably encounter in the real world to a digital certificate is a diploma or degree from an educational institution. and to take this anaology to the final step University of Cambridge is the Root - you know and trust. other Universities and Technical colleges are roots too - you know and trust them (your certificate store/keychain will be full of trusted Roots) - however, other orgs can hand out degrees too...these are affiliated to the main (root) CAs and have a lot of rules/checks/balances so, john smith, Degree from College of Town, underwritten by University of Foo you trust Fooso you then trust College of Town which means you trust the degree John holds. College of Town is, in this case, an intermediate Certificate. alan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Diffie hellman - Open SSL Client and C# Server
DH Exchange algorithm has to be negotiated in the SSL handshake . I was assuming that DH has to be implemented out side the SSL. I am wrong I had implemented complete with SSL from starch .As .Net SSL stream don't support Diffie Hellman and it worked i am able to communicated with DH Open SSL client.. I am parsing DH Public params from .pem file of Open SSL. -- View this message in context: http://openssl.6102.n7.nabble.com/Diffie-hellman-Open-SSL-Client-and-C-Server-tp47524p49597.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: SSL Root CA and Intermediate CA Certs.
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
us...@openssl.org] On Behalf Of Kaushal Shriyan
I am new to SSL/TLS Certificates. Please help me understand what is the
difference between ROOT CA Certs and Intermediate Certs or Chain Certs. I
will appreciate if i can refer to some books or tutorials to know about
SSL/TLS
technology.
I don't know how you learn about SSL/TLS, other than (a) reading the internet,
and working on it a lot, (b) taking some courses on general cryptography (there
is a free online course at coursera.com, which is quite good.) and (c) the
thing that I actually found the most useful, a general book on cryptography
called Cryptography Engineering, by Bruce Schneier, Niels Ferguson, Tadayashi
Kohno.
The root cert is self signed (so it is signed by itself.) The intermediate
cert is signed by the root cert. And your leaf cert is signed by the
intermediate.
A client who receives the cert chain (the root, intermediate, and leaf) can
follow a process to (1) verify that the leaf cert is not corrupted, and that
the intermediate cert has verified it. (b) verify that the intermediate cert
is not corrupted, and that the root cert has verified it, and that the
intermediate cert is in fact authorized by the root cert to perform the
authorization of the leaf cert. and (c) verify that the root cert is among the
list of certs that the client trusts.
How and why do you trust any root certs? Generally they're built-in to your OS
or your browser, so you're just blindly trusting that those guys know what
they're doing.
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
A problem about the memory-BIO
A problem about the memory-BIO, where i set an SSL with two diffrent BIOs,i get error READ CLIENT HELLO B when TLS handshake.And where i set the same BIO to SSL,it says READ CLIENT HELLO A. My question is why this occurs,and what does READ CLIENT HELLO A/B mean? zyf01...@gmail.com
