> From: owner-openssl-us...@openssl.org On Behalf Of thorso...@lavabit.com > Sent: Tuesday, 06 November, 2012 23:15 > To: openssl-users@openssl.org > Subject: CA.pl, TLS encryption, Postfix > > Hello, > > I need help with CA.pl and this [1] guide in general. > > (I've already tried to ask here [2].) > > My goal is to configure Postfix to support TLS encryption. First, I'd > like to configure it to use my system login/pass pair for auth <snip> > Should I create another user?
Can't help you there, that's not a TLS issue. > Should I use another method (e.g. client certs)? > If it works for your clients and you and/or they prefer it, yes. If your clients don't already have or get certs you trust, you can use OpenSSL to issue client certs (and possibly keys depending on client capabilities) -- and obviously you can trust yourself. > Second, I have some troubles with understanding this [2] process. > > The following is from CA.pl: > > $ openssl req $SSLEAY_CONFIG -new -keyout > ./demoCA/private/./cakey.pem \ > > -out ./demoCA/./careq.pem > > What are we doing here? Creating a privatekey/keypair in the cakey.pem file, as configured in the config file (conventionally RSA) and a CSR (Certificate Signing Request) in careq.pem for the publickey part of that keypair with a name you either entered or pre-congifured in the config file. > My "SSLEAY_CONFIG" variable is empty. Should I adjust it? > If you want to use the default (installed) config file, no. If you want to use a different config file, either specify -config file directly or use any envvar you like to do so. While it is possible, assuming permission, to edit the default config file, if you want to make (any) changes I recommend making a copy and editting and using that, so you still have the original as a reference, and your changes aren't lost if/when you upgrade openssl. > $ openssl ca $SSLEAY_CONFIG -create_serial -out > ./demoCA/./cacert.pem \ > > -batch -keyfile ./demoCA/private/./cakey.pem -selfsign \ > > -extensions v3_ca -infiles ./demoCA/./careq.pem > > What is "create_serial"? Can't find it in the man page. > It's -create_serial and you're right it doesn't seem to have gotten added to the man page or help message. It does what it says -- creates the serial file if it doesn't exist. Alternatively you can create serial by hand -- it's a text file containing one line containing an even number of hex digits representing an octet string which is the first/next serial value. Serials only really matter if you issue more than one cert under the same CA (name), then they must be unique and openssl ca's (and IIRC also x509 -CA*'s) use of a file to track this is more convenient and reliable than doing it by hand. > Here is my attempt: > > openssl req -new -newkey rsa:2048 \ > -keyout cakey.pem \ > -out careq.pem > ... > Please enter the following 'extra' attributes > to be sent with your certificate request > A challenge password []: > > Should I use a challenge password? > Not when you are also the CA. When sending a request to a real CA, it's up to the CA whether they want this or not. > openssl ca -create_serial -out cacert.pem \ > -batch -keyfile cakey.pem -selfsign \ > -extensions v3_ca -infiles careq.pem > > How to adjust /usr/lib/ssl/openssl.cnf to let the above commands work > for every dir? (The above command returned several errors.) > The default/standard config file, if you/anyone hasn't changed it, uses directories ./demoCA and ./demoCA/private . Either use those dirs, or use a changed config file (as above). Or, don't use 'ca' at all; 'req' with some more arguments can generate the selfsigned cert itself. The default config file location varies on different platforms and builds. I don't know if /usr/lib/ssl/ is correct for your system. openssl version -d (or -a) will tell you. > Third, the main problem is that I don't understand the idea behind > this [2]. Why not use a single private key and a single cert? Please > elaborate. > I.e. ca* and fooserver* ? Certs from a real CA always require at least two levels and often more. The CA and the end-entity (your Postfix) are operated by different people with differing interests and requirements. Also best crypto practice is that a single key (thus cert) not be used for multiple "purposes", and cert issuance and SSL/TLS connection are considered different. For selfsigned certs like the above, it's a choice. A single key and cert (with broad keyUsage, or more easily just v1 which implies all keyUsage) can technically be used for both purposes. If you want to issue multiple certs (for example if you choose to use client certs and want to issue certs to multiple clients) it's usually easier to manage if you use the same approach as other CAs, instead of a plethora of selfsigned certs. Also if you intend to move later to a real CA and want to prepare/practice the configuration you will use then. However, if you simply want to use a selfsigned entity cert, to avoid confusion you should name it for the entity not ca*. > Finally, will the above commands plus this [2] instructions fulfill my > initial goal (i.e. TLS encryption for login auth)? Let's leave > SASL-related questions aside. > I didn't have time to go through all of 2, but if your server uses a key&cert/chain trusted by a client, it can be used to create a TLS connection which will be encrypted unless both endpoints configure an "eNULL" ciphersuite which is not the default in OpenSSL and not even allowed in some software precisely because it's insecure. Whatever data the server and client send over that connection is encrypted, and from my extremely vague understaing of SMTPS I think that includes login. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
