> From: owner-openssl-us...@openssl.org On Behalf Of Nathan Smyth > Sent: Friday, 01 February, 2013 08:47
> Is it possible to have null, untrusted, or shared > certificates, to simplify deployment for apps that don't care > about SSL? > > Basically I have an infrastructure that uses OpenSSL for > comms. As it is protocol based, it's important that > everything runs the same code (I.e. I don't want different > ports for non-SSL comms, and the SSL sockets require > different blocking mechanisms otherwise deadlocks). > > However, some applications using the infrastructure won't > care about TLS. To ease development/deployment for those, I > don't want them to have to define certificates, CAs, etc etc > for nothing. Rather, is there anyway I can package the code > such that there is a default (insecure certificate/CA) that > they can use which will work with other SSL clients (though > insecurely); or they can specify their own for real security? > So actually you do care about SSL/TLS, you just don't care about the authentication and possibly encryption features. > Essentially, just want some sort of default SSL certificate > that is accepted, can be used to establish a connection just > as any other, but doesn't actually provide security. > As discussed in your other thread, SSL/TLS defines and OpenSSL supports "aNULL" suites which use and need no fixed key&certs (but do need ephemeral keys or at least parameters, the same ones as authenticated DHE and ECDHE suites). Alternatively, you can share key&cert for systems using the "normal" (authenticating) suites, with the caveat roughly as you stated -- if you share "mysecretkey" with 5 or 20 or 300 systems, and their admins and maybe users, it isn't secret anymore and doesn't provide any real security. But it does allow the code and protocol to work the same. 1A. Simplest is to create one key, and a selfsigned cert for that key. Use that key/cert as the server key/cert for each server, and as the client key/cert for each client if you use client-auth as I think you said you do. Also make that cert a trusted "CA" cert on each client, and on each server if using client-auth. If you want the same system(s), or install package(s), to support "real" certs as well, you need a truststore that includes your selfsigned cert plus a suitable set of real CAs; if you have a special config or install for "insecure" systems that truststore can be your selfsigned cert and nothing else. 1B. Slightly more realistic is to create your own CA (cakey and cacert) and your own EE key and EE cert using that CA. Then make the EE key/cert the server key/cert for each server and the client key/cert for each client if applicable, and the *CA* cert a trusted CA cert for each client and each server if applicable. Truststore issues same as 1A. 1C. Create one EE key, and get an EE cert from a real CA for it. This probably costs you a few bucks a year. Make that EE key/cert the server key/cert and client key/cert if applicable. If your systems need to make any other SSL (authenticated) connections they probably already have a truststore containing the usual-suspect CAs, if not add one. 2. OpenSSL itself does not care about domain name(s) in the cert. If your application does, as most should, and cannot be overridden, you must have the name(s) in the cert match the name(s) used by the clients for the servers, and possibly the name(s) of the clients seen by the servers (but that's rarer). 2A. One way is to put in the cert all the server domain names, or if they are all "neighbors" like fred.example.com george.example.com fruitbat.example.com put a single wildcard for them. You can have one name in the SubjectName in the cert, or multiple names (including wildcards) in the SubjectAlternativeName extension. For 1A and 1B, OpenSSL will let you put any name(s) you wish in your cert, although configuring values for SAN is clumsier than for Subject. For 1C, the CA may charge extra for SAN and usually will limit the name(s) to a domain you "own" and any subdomains under it. 2B. The other way is to choose name(s) or wildcard(s) in the cert and then create domain names for the servers matching the name(s) in the cert. These can be aliases using CNAME. This requires you have authority to put things in your DNS zone, or alternatively authority to add DNS entries on each client that needs them using an "etc/hosts" file or similar. If your servers reverse-lookup their clients, you have to *replace* the PTR entries which may be less desirable, and I'm not sure etc/hosts works reliably (although on my captive Windows test systems, it usually does). But one warning: be sure your users understand this is not secure. For some people just telling them, even repeatedly, is not enough. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
