Re: Getting at the details of the client's requestes cipher suites
[sorry for top posting] This begs the question what is your access to the encrypted datastream? If you are sniffing from the wire using Wireshark, then it will decode to this level and show you a textual representation of the cipher list. If you have access to the datastream through code, then you will have to decode the client hello message yourself. This assumes that you have access to the datastream before it enters OpenSSL (using BIO pairs, etc) Regards, Carl On Mon 08/10/12 10:29 PM , Hugo Maxwell Connery h...@env.dtu.dk sent: Hi OpenSSLers, During the TLS handshake the client suggests a list of cipher suites (and then negotiation occurs). I want to know what the client suggested. In text (or with ways to translate bits to said text/acronyms). Is there a trivial way to do this? I want to expose the nature of the negotiation: * it said: A, B, C or D (these cipher suites please) * server said: B I want the A, B, C or D part. Is there an easy way to do this? Regards, -- Hugo Connery, Head of IT, DTU Environment http://www.env.dtu.dk__ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-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: top 10 mistakes when using libopenssl?
- Original Message - From: Kyle Hamilton aerow...@gmail.com To: openssl-...@openssl.org; openssl-users openssl-users@openssl.org Sent: Thursday, October 11, 2012 3:08 AM Subject: Re: top 10 mistakes when using libopenssl? Suggestions from my experience: -Failing to verify the certificate after calling SSL_accept() -Failing to verify minimum cipher strength for the application -Failing to understand that the NULL suites give nothing and only take extra bytes eNULL suites provides authentication, they are not useless (as long as there is no requirement for secrecy). They can be used to ensure that data in transit does not get tampered with. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL Certificate Caching
Thanks Dave... In my test scenario, I am using a Firewall in between client and server machines and firewall supports SSL certificate caching. Here main thing is to test the firewall for SSL certificate caching. So wanted to establish multiple SSL connections from a single linux PC to the same server. That's the reason I was asking whether it's possible to send multiple SSL connections from single host. Please do let me know if there are any ways to test this scenario. Thanks, Sharan -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Thursday, October 11, 2012 1:18 AM To: openssl-users@openssl.org Subject: RE: SSL Certificate Caching From: owner-openssl-us...@openssl.org On Behalf Of Sharanagoud B D Sent: Tuesday, 09 October, 2012 06:39 Is there a option to specify a source interface along with openssl s_cleint option to establish multiple HTTP Connections from single linux device? This is required to test certificate caching scenario where need to have multiple clients trying to connect to a same server. For Ex: specify eth1:1, eth1:2..etc... 0. s_client doesn't do HTTP connections. It does SSL/TLS, only. If you feed it HTTP input (manually or from a file or program), you've got HTTPS. (s_server -www can do some minimal HTTPS.) 1. You can't specify an interface. You can't even specify a bind (local) address, which is how the usual socket interface (used by openssl) maps to a local interface. 2. You can have multiple connections from one client IP address to a given server IP address, because nearly all clients including s_client get unique port. Does the server need to see different addresses? If so, that will cause problems when used with NATted clients, which many these days are, especially on the public net. 3. If your server listens/accepts at multiple addresses, on a different subnet for each interface -- and listen-all (0.0.0.0 or ::0) is usually the default -- your IP stack should automatically use the matching client address. 4. If you can run virtual machines for the clients, you may be able to assign only selected interfaces and addresses to those virtual machines. This will depend on the particulars of the virtual machine software and I can't help there. 5. Or just use multiple real machines. Simple and foolproof. But do you really need this? If you are concerned about server behavior, you don't need s_client to test it; you can write a trivial program using openssl (which can bind), or find other client software. I've heard rumors perl or gawk can do such things, and I believe are standard on Linux. Java can definitely do it with about 20 lines of code -- that's what I use -- and is pretty easy to install (if you can instal software at all). If you are concerned about s_client behavior, it doesn't do any caching by itself. It uses exactly and only what's in static files that you can look at. Or it occurs to me, are you thinking about *session* caching (rather than certificates)? openssl library does support session caching within a process, or through some kind of shared storage, but s_client will only re-use a session if you explicitly specify -sess_out and -sess_in . __ 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: SSL Certificate cache
Thank you Dave. My setup is: Attacker Linux PC (Client)-- SSLFP-Firewall ---Victim Linux PC (Server) Here, Firewall supports SSL certificate caching, So just wanted to know whether certificate cached from firewall can be viewed in Client PC. This firewall is SSL Forward proxy. I think -showcerts in openssl shows the certificate which is cached right? Thanks, Sharan -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Thursday, October 11, 2012 1:18 AM To: openssl-users@openssl.org Subject: RE: SSL Certificate cache From: owner-openssl-us...@openssl.org On Behalf Of Sharanagoud B D Sent: Tuesday, 09 October, 2012 06:25 How to check in Linux client device whether the certificate used is cached or it's from the server? I am using openssl s_client to establish http connection. By the certificate used do you mean the server's cert? That must always be sent by the server; even if the client has a copy already, the client does not know which one it is. (It is *not* required that the same server name, or address, always use the same key+cert, and some don't.) If you mean chain certs above entity and below root: - you can see what the server sends with -showcerts on s_client - s_client uses openssl's standard truststore, a file and/or directory in specified or default locations. You can look at that file and/or directory to see what certs are in it. - verification is the same either way; so it shouldn't matter, unless there are multiple certs for the same CA subject. Public CAs generally change subject for new generation etc., but sometimes reuse subject to lengthen validity of an existing subtree or provide an alternate (or just changed) trust path to a subtree. If the server sends the root cert for its cert, openssl client including s_client doesn't use it. openssl only trusts roots in its local truststore. OTOH if you mean a *client* cert -- used for client auth, which is rare -- s_client uses only a cert explicitly specified on the command line, and you know what you specified. __ 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
PKCS7 open and extract signature
I have a PKCS7 file with signature in the envelope. What API function can I use to open the PKCS7 to extract the signature data and length and then verify the message digest? The verify is shown below assuming I got the signature data and length. int rc = ECDSA_verify(0, md, 20, signaturedata, signaturelength, pubeckey); Kinda hard to find the right functions which seems to be a pretty common thing. I did search the forum for this. -- View this message in context: http://old.nabble.com/PKCS7-open-and-extract-signature-tp34542036p34542036.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: PKCS7 open and extract signature
On 10/11/2012 1:59 PM, redpath wrote: I have a PKCS7 file with signature in the envelope. What API function can I use to open the PKCS7 to extract the signature data and length and then verify the message digest? The verify is shown below assuming I got the signature data and length. int rc = ECDSA_verify(0, md, 20, signaturedata, signaturelength, pubeckey); Kinda hard to find the right functions which seems to be a pretty common thing. I did search the forum for this. There are two APIs for this: CMS_verify() and PKCS7_dataVerify() Each with a lot of related sibling functions. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: PKCS7 open and extract signature
On Thu, Oct 11, 2012, redpath wrote: I have a PKCS7 file with signature in the envelope. What API function can I use to open the PKCS7 to extract the signature data and length and then verify the message digest? The verify is shown below assuming I got the signature data and length. int rc = ECDSA_verify(0, md, 20, signaturedata, signaturelength, pubeckey); Kinda hard to find the right functions which seems to be a pretty common thing. I did search the forum for this. It is not a good idea to try and verify the PKCS#7 signature manually as the signature is (usually) not the digest of the contents. Instead the content digest is contained in a set of attributes and the signature is performed on the digest of the attributes. PKCS7_verify or CMS_verify will both perform the necessary operations along with the cms and smime command line options. See the manual pages for more details there are also demo programs in demos/smime and demos/cms. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: PKCS7 open and extract signature
Well the situation is I have a file which has been signed for its contents. This signature is used to verify the authentication of the file. The signature works great but I want to use best practices to package the signature. A PKCS7 was suggested. So I assume I can extract this signature from the PKCS7 to verify the file contents which I create the message digest SHA2 from. Is there something I am missing here. Just want to use best practices. The challenger has the file and the PKCS7 (signature) to verify the contents. The challenger has the public key. redpath wrote: I have a PKCS7 file with signature in the envelope. What API function can I use to open the PKCS7 to extract the signature data and length and then verify the message digest? The verify is shown below assuming I got the signature data and length. int rc = ECDSA_verify(0, md, 20, signaturedata, signaturelength, pubeckey); Kinda hard to find the right functions which seems to be a pretty common thing. I did search the forum for this. -- View this message in context: http://old.nabble.com/PKCS7-open-and-extract-signature-tp34542036p34542704.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: PKCS7 open and extract signature
On 10/11/2012 4:16 PM, redpath wrote: Well the situation is I have a file which has been signed for its contents. This signature is used to verify the authentication of the file. The signature works great but I want to use best practices to package the signature. A PKCS7 was suggested. So I assume I can extract this signature from the PKCS7 to verify the file contents which I create the message digest SHA2 from. This sounds like you want a detached PKCS#7 signature, where the PKCS#7 structure itself contains some meta-information about the file (such as what hash algorithm to use and what date the signature was made), but not the actual file contents. Detached PKCS#7 signatures are very common, this is how PKCS#7 is used with signed (but not encrypted) e-mails, Microsoft Authenticode signatures and many other uses. The function families suggested to you also contain functions that can generate and validate detached PKCS7 signatures. Is there something I am missing here. Just want to use best practices. The challenger has the file and the PKCS7 (signature) to verify the contents. The challenger has the public key. It is currently considered best practice to provide the public key in the form of an X.509 certificate issued by someone the challenger probably trusts with the ability to independently verify that you are who you say you are. This will be provided to the challenger in two places (that must agree): 1. Inside the PKCS#7 structure (there is a field specifically for that). 2. Separately over a trusted delivery mechanism (so the challenger has another reason to be certain he has the proper public key to trust with signing the file contents). redpath wrote: I have a PKCS7 file with signature in the envelope. What API function can I use to open the PKCS7 to extract the signature data and length and then verify the message digest? The verify is shown below assuming I got the signature data and length. int rc = ECDSA_verify(0, md, 20, signaturedata, signaturelength, pubeckey); Kinda hard to find the right functions which seems to be a pretty common thing. I did search the forum for this. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
connection with two-way SSL authentication in OpenSSL
Hi All Does anybody know how establish connection with two-way SSL authentication in OpenSSL? I have read chapter 5 SSL/TLS programming in Network security with openSSL book, but couldn't find information about it. Best regards xidex
Re: connection with two-way SSL authentication in OpenSSL
On 10/11/2012 4:48 PM, Abyss Lingvo wrote: Hi All Does anybody know how establish connection with two-way SSL authentication in OpenSSL? I have read chapter 5 SSL/TLS programming in Network security with openSSL book, but couldn't find information about it. Two way SSL/TLS authentication is also known as SSL/TLS client authentication or as SSL/TLS with client certificates. Those other names are what is used most in the OpenSSL documentation, on this mailing list, and probably in that book (which I have not read). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
id-aes256-GCM command line encrypt+decrypt fail
Hello, I am trying to encrypt and decrypt a string using command-line openssl (1.0.1c) with the id-aes256-GCM algorithm, but every time it fails echo -n bla | openssl enc -e -id-aes256-GCM -nosalt -a -out t.out openssl enc -d -id-aes256-GCM -nosalt -a -in t.out bad decrypt This is true whether I use manually specified key/IV or password, with or without salt. The same commands work with other algorithms. What am I missing? Thanks Mark
Re: id-aes256-GCM command line encrypt+decrypt fail
See: http://marc.info/?l=openssl-usersm=134867395821086w=2 On 11 October 2012 17:19, e...@mit.edu e...@mit.edu wrote: Hello, I am trying to encrypt and decrypt a string using command-line openssl (1.0.1c) with the id-aes256-GCM algorithm, but every time it fails echo -n bla | openssl enc -e -id-aes256-GCM -nosalt -a -out t.out openssl enc -d -id-aes256-GCM -nosalt -a -in t.out bad decrypt This is true whether I use manually specified key/IV or password, with or without salt. The same commands work with other algorithms. What am I missing? Thanks Mark
BN_clear_free and BN_CTX_free deprecated?
Hi All, I'm revisiting some code I wrote a few years ago. During compilation on a MacBook, I got a number of warnings due to deprecation: SRPCommon.cpp: In destructor ‘virtual BigNumCleanup::~BigNumCleanup()’: SRPCommon.cpp:52: warning: ‘BN_clear_free’ is deprecated (declared at /usr/include/openssl/bn.h:419) SRPCommon.cpp:52: warning: ‘BN_clear_free’ is deprecated (declared at /usr/include/openssl/bn.h:419) SRPCommon.cpp: In destructor ‘virtual BigNumCtxCleanup::~BigNumCtxCleanup()’: SRPCommon.cpp:66: warning: ‘BN_CTX_free’ is deprecated (declared at /usr/include/openssl/bn.h:407) SRPCommon.cpp:66: warning: ‘BN_CTX_free’ is deprecated (declared at /usr/include/openssl/bn.h:407) Has OpenSSL deprecated these functions? I don't see it mentioned in the documents (http://www.openssl.org/docs/crypto/BN_new.html). Or is this more crap from Cupertino? Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Generating rsakey using openssl as lib
Hi all, I have an application which already establishes SSL Socket connection using OpenSSL as lib. Now, my application needs to able the user create a RSA key pair, sign documents and verify signatures. This it will be needed in some features of my application, managed by user for signing docs and verifying signatures. The point is not do this by prompt because it will force install openssl in all computer which the application is installed. The idea is call some function from Openssl lib already imported by my application in order to create and use key pair. My question is, what's the better (or easier) way to make it happen? I'm thinking in call the function which the openssl prompt calls, then, Openssl lib will generate and store the key already in pem format, into a directory specified by application. The same about sign docs and verify signatures. Other way it would be to call rsa functions directly and code it for pem format. I have no idea which one is easier or better. I'm reading openssl docs and source code, but I'm still a bit lost how to make it works. I really appreciate any help on it. Leonardo
Re: connection with two-way SSL authentication in OpenSSL
You might want to look at EAP-TLS. On 12 October 2012 03:55, Jakob Bohm jb-open...@wisemo.com wrote: On 10/11/2012 4:48 PM, Abyss Lingvo wrote: Hi All Does anybody know how establish connection with two-way SSL authentication in OpenSSL? I have read chapter 5 SSL/TLS programming in Network security with openSSL book, but couldn't find information about it. Two way SSL/TLS authentication is also known as SSL/TLS client authentication or as SSL/TLS with client certificates. Those other names are what is used most in the OpenSSL documentation, on this mailing list, and probably in that book (which I have not read). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ 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: id-aes256-GCM command line encrypt+decrypt fail
I think Steve posted a while back that those ciphers require special handling and do not work with the enc command yet. Erik Tkal Juniper OAC/UAC/Pulse Development From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of e...@mit.edu Sent: Thursday, October 11, 2012 12:19 PM To: openssl-users@openssl.org Subject: id-aes256-GCM command line encrypt+decrypt fail Hello, I am trying to encrypt and decrypt a string using command-line openssl (1.0.1c) with the id-aes256-GCM algorithm, but every time it fails echo -n bla | openssl enc -e -id-aes256-GCM -nosalt -a -out t.out openssl enc -d -id-aes256-GCM -nosalt -a -in t.out bad decrypt This is true whether I use manually specified key/IV or password, with or without salt. The same commands work with other algorithms. What am I missing? Thanks Mark
RE: OpenSSL cert authority with no database
I hit this EXACT problem. The *wrong* ways to solve it are to keep deleting the database or deleting records from the database. The right way to solve it is to revoke certificates that you want to re-issue. I just happen to have a (Windows - sorry if you're not Windows) .BAT file to do just that, and as a side benefit, it maintains a CRL that you can play with. (You do intend to support CRLs, right?) rem revoke a certificate and re-issue the CRL rem unable to write 'random state' seems to be normal rem pass the name of the PEM file to be revoked as the only argument openssl.exe ca -revoke %1 -config myConfig.cnf -keyfile myRoot.key.pem -passin pass:the_password openssl.exe ca -gencrl -out myRevocations.crl -config myConfig.cnf -keyfile myRoot.key.pem -passin pass:the_password pause Check status of certificate revocation and CRL generation (CRL *success* outputs no messages) Charles From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Derek Cole Sent: Thursday, October 11, 2012 3:14 PM To: openssl-users@openssl.org Subject: OpenSSL cert authority with no database Hello, Is there a way to sign certificates with your own CA, and NOT have to use a database file to keep track of them? For development purposes, I end up creating the same cert multiple times, and trying to sign it which will cause me to get the TXT_DB error number 2 sometimes, which does not allow the signing of the cert to proceed. Thanks!
Re: OpenSSL cert authority with no database
On Thu, Oct 11, 2012, Derek Cole wrote: Hello, Is there a way to sign certificates with your own CA, and NOT have to use a database file to keep track of them? For development purposes, I end up creating the same cert multiple times, and trying to sign it which will cause me to get the TXT_DB error number 2 sometimes, which does not allow the signing of the cert to proceed. The x509 utility can be used to generate certificates too, see the manual page and the sample scripts in demos/certs Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL cert authority with no database
Thanks for the quick response. I hadn't thought about CRL at this point actually.. I am just wading into this trying to get minimal functionality first. In case anyone is wondering, I also found that if you make a database.attr file to go with database, you can add unique_subject = no for a workaround until implementing something more stable. -Derek On Thu, Oct 11, 2012 at 6:34 PM, Charles Mills charl...@mcn.org wrote: I hit this EXACT problem. ** ** The **wrong* *ways to solve it are to keep deleting the database or deleting records from the database. ** ** The right way to solve it is to revoke certificates that you want to re-issue. I just happen to have a (Windows – sorry if you’re not Windows) .BAT file to do just that, and as a side benefit, it maintains a CRL that you can play with. (You do intend to support CRLs, right?) ** ** rem revoke a certificate and re-issue the CRL rem unable to write 'random state' seems to be normal rem pass the name of the PEM file to be revoked as the only argument ** ** openssl.exe ca -revoke %1 -config myConfig.cnf -keyfile myRoot.key.pem -passin pass:the_password ** ** openssl.exe ca -gencrl -out myRevocations.crl -config myConfig.cnf -keyfile myRoot.key.pem -passin pass:the_password ** ** pause Check status of certificate revocation and CRL generation (CRL *success* outputs no messages) ** ** *Charles* *From:* owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] *On Behalf Of *Derek Cole *Sent:* Thursday, October 11, 2012 3:14 PM *To:* openssl-users@openssl.org *Subject:* OpenSSL cert authority with no database ** ** Hello, Is there a way to sign certificates with your own CA, and NOT have to use a database file to keep track of them? For development purposes, I end up creating the same cert multiple times, and trying to sign it which will cause me to get the TXT_DB error number 2 sometimes, which does not allow the signing of the cert to proceed. Thanks!
RE: Best practice for client cert name checking
Thanks. My boss is not technical. I am the CTO of this product. Our customers are your basic commercial customers. Yes, I picture that they would be their own CA. Why pay Verisign if you don't have a bunch of people sitting at their PCs trying to buy widgets from your Web site, and wondering if they can trust it. Yes, I support a local CRL file. I think our customers' situation is likely a LOT like yours: relatively few machines, possibly distant and possibly on the public Internet. It's basically an unattended box to unattended box product, so the problem is identifying machines, not people. Yes, IP addresses change. Obviously if someone is changing IP addresses a lot they would have to change the whitelist a lot. I've got other fish to fry at the moment, but I kind of like the idea of offering if and only if the 'names' on the whitelist are IP addresses then one (possibly wildcarded in the low-order node) must compare equal to the incoming IP address, and the incoming IP address must also compare equal to a (possibly wildcarded) name in the certificate. This would *help* (everything is a help, right, nothing is absolute) with the problem of a client certificate that got away into the wild, right? Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Wednesday, October 10, 2012 12:48 PM To: openssl-users@openssl.org Subject: RE: Best practice for client cert name checking From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills Sent: Monday, 08 October, 2012 07:47 Dave, any thoughts on my original question? My thread kind of got hi-jacked. Not much, but since you ask: -Original Message- From: Charles Mills [mailto:charl...@mcn.org] Sent: Saturday, October 06, 2012 9:52 AM To: openssl-users@openssl.org Subject: Best practice for client cert name checking I have recently written a product that incorporates SSL/TLS server code that processes client certificates. I designed what I thought made sense at the time but now I am wondering if what I did was best. Whatever you, or your users/boss/customers/etc., need. The technical question is do you use -- that is, have your clients use -- public CAs (like Verisign etc.) or a CA that you control (operate or contract with)? If the latter, maybe you can limit issuance so that any cert issued by this CA and not revoked is a good client. (Although for openssl revocation checking to be accurate, either you must have some method to update CRLs often enough or you must implement OCSP.) In the product's configuration file the sysadmin may optionally include a whitelist of client names. If the sysadmin does so, then the server requests a client certificate. At least one of the names (subject O= and Alternative names, including wildcards) in the certificate must match one of the names in the whitelist or I reject the session. For public certs you may want CN (Common Name) as well as or even instead of O (Organization). Something I saw recently got me to wondering whether I should have made some sort of provision for checking IP addresses: perhaps verifying that the client IP address appeared in the Alternative names in the client certificate as well as in the whitelist? Or perhaps that the IP address matched an alternative name and the subject name appeared in the whitelist? I wouldn't. In much of today's internet IP addresses are not very stable at identifying machines, and even less so people. But it's up to your users/etc what they need, or want. FWIW, I work in a back-end environment where the systems that connect are relatively few and very stable, though distant, so we just have our own CA which issues certs to only valid clients. Your situation is likely different. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Firefox unhappy with my self signed Cert
Hello, I sort of posted about this earlier, but I think this is a more concise question (as the previous replies were helpful for me to start debugging the problem). i have a server that is running a custom app that can accept a SSL connection. I generate a cert on each server, that is signed by my own CA. I tested whether this worked or not by using the openssl s_client and s_server commands, and it actually worked to connect to the server using those commands. I started the server with a PEM file that contained the signed cert request, as well as the private key for that cert request. This allowed me to start the server with openssl s_server -accept 443 -cert myfile.cert and on the client side openssl s_client -connect myserver:443 -CAfile my_server_cert.pem This gave me a verify code of zero, so I thought I was good to go. I installed my_server_cert.pem as a trusted authority in firefox, however, it still prompts that it is an Untrusted Connection and has the button to add security exception. When I click this button, I noticed that under Certificate Status it says Wrong Site and This iste attempts to identify itself iwth invalid information I'd prefer my clients to not have this pop-up when they are connecting to my servers. From the server side, when I debug the app, I see I get the sslv3 alert bad certificate error at first, and then the next connection's are SSL_accepted() as the client requests cert status and such, until i'm finally done adding the security exception, and my final SSL_accept() finally gets a return of 1 which I was hoping for. Is this just a firefox bug or what? I have noticed too, that I am able to launch my custom app, and use openssl s_client -connect to connect to that same server, same certs, and it gives me verify code zero. Thanks for any insight.
RE: Firefox unhappy with my self signed Cert
How do you specify the name (URL) of the Web site in Firefox? Do you use exactly the same name as you use with the test client (and the name in the certificate)? Firefox is saying the certificate is for myserver but you are specifying a different name when you open the site. The name has to be exactly the same as one of the names (including alternates) in the certificate. (You can wildcard the last node in the alternate names.) myserver is not the same as myserver.com Charles From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Derek Cole Sent: Thursday, October 11, 2012 4:03 PM To: openssl-users@openssl.org Subject: Firefox unhappy with my self signed Cert Hello, I sort of posted about this earlier, but I think this is a more concise question (as the previous replies were helpful for me to start debugging the problem). i have a server that is running a custom app that can accept a SSL connection. I generate a cert on each server, that is signed by my own CA. I tested whether this worked or not by using the openssl s_client and s_server commands, and it actually worked to connect to the server using those commands. I started the server with a PEM file that contained the signed cert request, as well as the private key for that cert request. This allowed me to start the server with openssl s_server -accept 443 -cert myfile.cert and on the client side openssl s_client -connect myserver:443 -CAfile my_server_cert.pem This gave me a verify code of zero, so I thought I was good to go. I installed my_server_cert.pem as a trusted authority in firefox, however, it still prompts that it is an Untrusted Connection and has the button to add security exception. When I click this button, I noticed that under Certificate Status it says Wrong Site and This iste attempts to identify itself iwth invalid information I'd prefer my clients to not have this pop-up when they are connecting to my servers. From the server side, when I debug the app, I see I get the sslv3 alert bad certificate error at first, and then the next connection's are SSL_accepted() as the client requests cert status and such, until i'm finally done adding the security exception, and my final SSL_accept() finally gets a return of 1 which I was hoping for. Is this just a firefox bug or what? I have noticed too, that I am able to launch my custom app, and use openssl s_client -connect to connect to that same server, same certs, and it gives me verify code zero. Thanks for any insight.
Re: Firefox unhappy with my self signed Cert
On 12 Oct 2012, at 1:03 AM, Derek Cole derek.c...@gmail.com wrote: I installed my_server_cert.pem as a trusted authority in firefox, however, it still prompts that it is an Untrusted Connection and has the button to add security exception. When I click this button, I noticed that under Certificate Status it says Wrong Site and This iste attempts to identify itself iwth invalid information What DNS name did you insert into the certificate, and does this DNS name match the name of the site you're connecting to exactly? One of the key purposes of an SSL cert in an https connection is to verify that you are actually connecting to the site you think you're connecting to. If the DNS names don't match, the connection will fail, as it should. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Firefox unhappy with my self signed Cert
On 12 Oct 2012, at 1:40 AM, Charles Mills charl...@mcn.org wrote: How do you specify the name (URL) of the Web site in Firefox? Do you use exactly the same name as you use with the test client (and the name in the certificate)? Firefox is saying the certificate is for myserver but you are specifying a different name when you open the site. The name has to be exactly the same as one of the names (including alternates) in the certificate. (You can wildcard the last node in the alternate names.) myserver is not the same asmyserver.com If you see http://mysite.somewhere; in your browser, then the name mysite.somewhere needs to be embedded in the certificate, and this need to be precise. You can't arbitrarily leave parts of the names out, or insert some kind of approximation (with the exception of a wildcard entry in a cert, subject to specific rules). What URL are you typing into Firefox? What DNS name have you embedded into the cert, and how have you done it? Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
RE: Generating rsakey using openssl as lib
From: owner-openssl-us...@openssl.org On Behalf Of Leonardo Laface de
Almeida
Sent: Thursday, 11 October, 2012 14:04
I have an application which already establishes SSL Socket connection
using OpenSSL as lib. Now, my application needs to able the user create
a RSA key pair, sign documents and verify signatures. This it will be
needed in some features of my application, managed by user for signing
docs and verifying signatures.
The point is not do this by prompt because it will force install openssl
in all computer which the application is installed. The idea is call some
function from Openssl lib already imported by my application in order to
create and use key pair.
I assume by prompt you mean the commandline aka utility executable
openssl (openssl.exe on Windows)? Note this executable can run with
input as commandline args or from a file or pipe without prompting.
If your application uses openssl as dynamic library(ies), as is the
usual configuration on most systems, you already need the openssl
library(ies) installed for your application to work. If so, presumably
you've already handled that, and that install probably could and
maybe did include the commandline executable.
But yes, everything significant openssl does is done by calling
library functions that your application(s) can call.
My question is, what's the better (or easier) way to make it happen?
A common standard way of doing signatures on data is CMS-formerly-PKCS7,
see thread PKCS7 open and extract signature just in the past few days.
I'm thinking in call the function which the openssl prompt calls, then,
Openssl lib will generate and store the key already in pem format,
into a directory specified by application. The same about sign docs
and verify signatures.
Almost. See RSA_generate_key to generate a key, or EVP_keygen*
for the new-1.0.0 more generic way, and PEM_write[_bio]_RSAPrivateKey
to write the specific legacy form or PEM_write[_bio]_PKCS8PrivateKey
for the (less new) generic form. And similarly to read back.
If these files are only stored locally and a human needn't look at them,
you could use DER format instead of PEM. But there's little benefit.
Other way it would be to call rsa functions directly and code it for pem
format.
You can call RSA_* directly, or you can use the generic EVP_* routines
with an RSA key, which is where recent development effort has focussed.
If you want CMS, openssl has a module for that (and for SMIME_,
which is really CMS under the covers), which actually uses EVP_*,
with routines to write and read the structure in PEM. If you design
your own structure, you'll need to implement it yourself, though openssl
can do base64 using a BIO (directly to/from a file, or in memory)
or just EVP_{en,de}code directly.
All of these are routines that commandline can use, depending on
the subcommand you choose and the arguments you give it.
I have no idea which one is easier or better. I'm reading openssl docs
and source code, but I'm still a bit lost how to make it works.
Hope this helps. If you have more specific questions ask again.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: PKCS7 open and extract signature
From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm Sent: Thursday, 11 October, 2012 10:45 On 10/11/2012 4:16 PM, redpath wrote: Well the situation is I have a file which has been signed for its contents. This signature is used to verify the authentication of the file. The signature works great but I want to use best practices to package the signature. A PKCS7 was suggested. So I assume I can extract this signature from the PKCS7 to verify the file contents which I create the message digest SHA2 from. This sounds like you want a detached PKCS#7 signature, where the PKCS#7 structure itself contains some meta-information about the file (such as what hash algorithm to use and what date the signature was made), but not the actual file contents. Detached PKCS#7 signatures are very common, this is how PKCS#7 is used with signed (but not encrypted) e-mails, Microsoft Authenticode signatures and many other uses. The function families suggested to you also contain functions that can generate and validate detached PKCS7 signatures. Yes. PKCS#7 is now officially Cryptographic Message Syntax (CMS), much like SSL is now officially Transport Level Security (TLS). We often still use the old names loosely to mean both, but when implementing you may need to be more precise. Is there something I am missing here. Just want to use best practices. The challenger has the file and the PKCS7 (signature) to verify the contents. The challenger has the public key. It is currently considered best practice to provide the public key in the form of an X.509 certificate issued by someone the challenger probably trusts with the ability to independently verify that you are who you say you are. This will be provided to the challenger in two places (that must agree): That someone is called a Certificate Authority or CA. The cert should be from a CA the challenger (this is usually called verifier or relier) *does* trust; the issue is whether the signer knows, at signing time, who the reliers are or will be and what CAs they do or will trust. If you do know, use that; otherwise you must guess. With PKCS7/CMS signed-data you can generate and include multiple signatures on the same data; these could be signatures using 2 (or 5 or 42) different certs that different reliers do or are expected or hoped to trust. 1. Inside the PKCS#7 structure (there is a field specifically for that). The PKCS7/CMS SignerInfo always includes a field to *identify* the signing key, usually by issuer+serial of the signer's cert. Signed-data *may* also include copies of any or all certs the relier(s) may need, starting with the signer's cert and going up the chain as necessary or desired. 2. Separately over a trusted delivery mechanism (so the challenger has another reason to be certain he has the proper public key to trust with signing the file contents). Not (normally) the signer's cert. A main feature of certs is they are signed and thus tamperprotected and authenticable, and so can be transmitted and/or stored without authentication or integrity protection. What does need to be passed to the relier(s) in a trusted way is the CA *root*, or other trust anchor, for the signer's cert. For public CAs like Verisign, this is usually done by the relier application or system installing a vendor-chosen set of public roots, which may be manually adjusted if necessary. E.g. Windows does this, and Firefox, and Java. Windows occasionally pushes updates as well, if you use Windows autoupdate (or one of Microsoft's enterprise updaters), which you pretty much must to handle the stream of security fixes in Windows. snip rest __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL Certificate cache
From: owner-openssl-us...@openssl.org On Behalf Of Sharanagoud B D Sent: Thursday, 11 October, 2012 07:38 My setup is: Attacker Linux PC (Client)-- SSLFP-Firewall ---Victim Linux PC (Server) Here, Firewall supports SSL certificate caching, So just wanted to know whether certificate cached from firewall can be viewed in Client PC. This firewall is SSL Forward proxy. What exactly is the firewall doing, and what do you mean by certificate caching? If it's just passthrough it can see initial handshake for each session, and could save certs from them, but can't use those certs for anything. In particular it can't modify any later session's intial handshake, or even see a renegotiation (unless negotiate eNULL then renegotiate, which is yucky). If it's terminating SSL from the client and sending clear to the server, it has whatever key+certs it's configured with, or if it wants to fool the client by having the real server's name(s?) in the cert -- I believe only for client using SNI, which few if any do -- it must be generating those certs (for a configured key or generated keys) on the fly or have access to an online CA that does so. Generated certs like that might be cached and re-used; if so you can recognize when the client gets a server (entity) cert it has seen before, or one it hasn't (which doesn't prove it wasn't used elsewhere). If it's terminating SSL from the client and initiating SSL to the server, i.e. a real SSL-level (or higher) proxy, it may be saving the server certs and related CA certs somewhere, but your client can't see them, because the cert and chain used to the client can't be the same. If it's doing client-auth on the server side, similarly it may have fixed or generated key+cert, but your client can't see it. If it's accepting client-auth from your client, which is rare, it may be saving that, but it can't use it on the server side. I think -showcerts in openssl shows the certificate which is cached right? -showcerts shows additional (chain) certs sent in the handshake by the server. The protocol does not indicate whether they were/are cached. Usually CA certs are static and it doesn't matter where they came from. s_client always shows the server=entity cert, if that's what you want. In another message you ask about multiple connections. To reduce traffic I am replying here. I assume you mean from s_client because that was your question earlier, although other clients are possible. If you mean serially, i.e. connection 1 then connection 2 then connection 3, that's trivial, so I assume that's not your question. If you mean concurrently, yes, just run several instances of s_client concurrently. It doesn't matter whether they are to the same server or not, each process and SSL connection is separate. You probably need to make their input interactive (thus each on a separate pty, shell window, or similar) or piped from a program that takes some time (like sleep 60) so you have time to type multiple commands and look at the results. If you want s_client connections to be in one SSL session i.e. negotiated authentication and session keyset, which nominally should be same client to same server, you can do that with -sess_out and -sess_in . But that skips the only usage of certs in the protocol, namely for authentication, so it seems unlikely to be what you want. Thanks, Sharan -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Thursday, October 11, 2012 1:18 AM To: openssl-users@openssl.org Subject: RE: SSL Certificate cache From: owner-openssl-us...@openssl.org On Behalf Of Sharanagoud B D Sent: Tuesday, 09 October, 2012 06:25 How to check in Linux client device whether the certificate used is cached or it's from the server? I am using openssl s_client to establish http connection. By the certificate used do you mean the server's cert? That must always be sent by the server; even if the client has a copy already, the client does not know which one it is. (It is *not* required that the same server name, or address, always use the same key+cert, and some don't.) If you mean chain certs above entity and below root: - you can see what the server sends with -showcerts on s_client - s_client uses openssl's standard truststore, a file and/or directory in specified or default locations. You can look at that file and/or directory to see what certs are in it. - verification is the same either way; so it shouldn't matter, unless there are multiple certs for the same CA subject. Public CAs generally change subject for new generation etc., but sometimes reuse subject to lengthen validity of an existing subtree or provide an alternate (or just changed) trust path to a subtree. If the server sends the root cert for its cert, openssl client including s_client doesn't use it.
RE: Firefox unhappy with my self signed Cert
From: owner-openssl-us...@openssl.org On Behalf Of Derek Cole Sent: Thursday, 11 October, 2012 19:03 i have a server that is running a custom app that can accept a SSL connection. I generate a cert on each server, that is signed by my own CA. I tested whether this worked or not by using the openssl s_client and s_server commands, and it actually worked to connect to the server using those commands. I started the server with a PEM file that contained the signed cert request, Nit: it contains the cert, and privatekey. A cert is NOT a signed CSR. as well as the private key for that cert request. This allowed me to start the server with openssl s_server -accept 443 -cert myfile.cert Note that will support connection at the SSL level, but not give an HTTP response unless you type it by hand (which is hard to do). Add -www to support minimal requests from browsers. and on the client side snip: s_client okay I installed my_server_cert.pem as a trusted authority in firefox, however, it still prompts that it is an Untrusted Connection and has the button to add security exception. [which] says Wrong Site and This iste attempts to identify itself iwth invalid information Most SSL clients including Firefox, unlike s_client, check that the name in the server cert matches the name of the server they want, almost always as a domain name. The traditional and simple way is the CommonName in the server cert's Subject field is the FQDN. Most clients, I'd expect including Firefox but didn't take time to test, also support (1-level) wildcard, or the SubjectAlternativeName extension which can have multiple domain names or wildcards or some other options that are rarely used. Public CAs often call this multi-domain, or Unified Communications which was Microsoft's jargon for it. If you're doing these certs yourself and can issue whatever you want free anytime, I'd go with simple, but openssl ca (or x509 -req) can do SAN if you set-up the config file(s). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Firefox unhappy with my self signed Cert
From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills Sent: Thursday, 11 October, 2012 19:40 Some minor points: How do you specify the name (URL) of the Web site in Firefox? Do you use exactly the same name as you use with the test client (and the name in the certificate)? OP's test client was openssl s_client, which does NOT check hostname, so that one doesn't matter. URL in Firefox/etc and name in cert do. Firefox is saying the certificate is for myserver but you are specifying a different name when you open the site. The name has to be exactly the same as one of the names (including alternates) in the certificate. (You can wildcard the last node in the alternate names.) myserver is not the same as myserver.com You can use wildcard in either Subject or SubjectAlternativeNames. The wildcard is the lowest-level component of a DNS name, which is at the left as written; in abstract that might be considered last but I think most people wouldn't call it that. snip earlier __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Firefox unhappy with my self signed Cert
The wildcard is the lowest-level component of a DNS name, which is at the left as written; in You're right (left?) of course. I was somehow picturing it incorrectly in my mind. I quick went and looked at my wildcard comparison code and it is correct (whew!). In my other thread about checking client IP addresses I was picturing a lowest-level/RIGHTmost wildcard on the IP address: e.g. 192.168.1.* That's lowest level conceptually but I guess not what the standard or convention provides for. BTW, a good quick discussion of wildcard certificate names: http://support.godaddy.com/help/article/567/what-is-a-wildcard-ssl-certifica te (They'd love to sell you one; this is not an endorsement.) Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Thursday, October 11, 2012 5:13 PM To: openssl-users@openssl.org Subject: RE: Firefox unhappy with my self signed Cert From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills Sent: Thursday, 11 October, 2012 19:40 Some minor points: How do you specify the name (URL) of the Web site in Firefox? Do you use exactly the same name as you use with the test client (and the name in the certificate)? OP's test client was openssl s_client, which does NOT check hostname, so that one doesn't matter. URL in Firefox/etc and name in cert do. Firefox is saying the certificate is for myserver but you are specifying a different name when you open the site. The name has to be exactly the same as one of the names (including alternates) in the certificate. (You can wildcard the last node in the alternate names.) myserver is not the same as myserver.com You can use wildcard in either Subject or SubjectAlternativeNames. The wildcard is the lowest-level component of a DNS name, which is at the left as written; in abstract that might be considered last but I think most people wouldn't call it that. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Firefox unhappy with my self signed Cert
Thanks to everyone for the information. I can't recall right now how I set up the name - I was thinking for sure it was with the FQDN, but I'll double check. I will do that reading and check tomorrow when I am back at work and see if I can figure out what is going wrong there. Thanks On Thu, Oct 11, 2012 at 8:41 PM, Charles Mills charl...@mcn.org wrote: The wildcard is the lowest-level component of a DNS name, which is at the left as written; in You're right (left?) of course. I was somehow picturing it incorrectly in my mind. I quick went and looked at my wildcard comparison code and it is correct (whew!). In my other thread about checking client IP addresses I was picturing a lowest-level/RIGHTmost wildcard on the IP address: e.g. 192.168.1.* That's lowest level conceptually but I guess not what the standard or convention provides for. BTW, a good quick discussion of wildcard certificate names: http://support.godaddy.com/help/article/567/what-is-a-wildcard-ssl-certifica te (They'd love to sell you one; this is not an endorsement.) Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Thursday, October 11, 2012 5:13 PM To: openssl-users@openssl.org Subject: RE: Firefox unhappy with my self signed Cert From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills Sent: Thursday, 11 October, 2012 19:40 Some minor points: How do you specify the name (URL) of the Web site in Firefox? Do you use exactly the same name as you use with the test client (and the name in the certificate)? OP's test client was openssl s_client, which does NOT check hostname, so that one doesn't matter. URL in Firefox/etc and name in cert do. Firefox is saying the certificate is for myserver but you are specifying a different name when you open the site. The name has to be exactly the same as one of the names (including alternates) in the certificate. (You can wildcard the last node in the alternate names.) myserver is not the same as myserver.com You can use wildcard in either Subject or SubjectAlternativeNames. The wildcard is the lowest-level component of a DNS name, which is at the left as written; in abstract that might be considered last but I think most people wouldn't call it that. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
