Este documento é derivado do documento encontrado em http://www.madboa.com/geek/openssl/.
Acrescentaram-se algumas parte em português, com vista a responder aos objectivos da disciplina prática.
Retiraram-se outras partes menos relevante para o desenrolar da aula. Para mais pormenores, consulte o original ou outra documentação.
Generating digests with the dgst option
is one of the more straightforward tasks you can accomplish with the
openssl binary. Producing digests is
done so often, as a matter of fact, that you can find special-use
binaries for doing the same thing.
Digests are created using the dgst
option.
# MD5 digest openssl dgst -md5 filename # SHA1 digest openssl dgst -sha1 filename
Use the built-in
list-message-digest-commands option to get a list of the
digest types available to your local OpenSSL installation.
openssl list-message-digest-commands
exercício: tente outros algoritmos
nota: a opção -sign não está disponível na versão 0.9.5a do openssl, daí que o exercício seguinte não seja possível na distribuição que se usa nas aulas.
If you want to ensure that the digest you create doesn't get
modified without your permission, you can sign it using your
private key.
The following example assumes that you want to sign the SHA1 sum of
a file called foo-1.23.tar.gz.
# signed digest will be foo-1.23.tar.gz.sha1 openssl dgst -sha1 -sign mykey.pem -out foo-1.23.tar.gz.sha1 foo-1.23.tar.gz
nota: a opção -sign não está disponível na versão 0.9.5a do openssl, daí que o exercício seguinte não seja possível na distribuição que se usa nas aulas.
To verify a signed digest you'll need the file from which the digest was derived, the signed digest, and the signer's public key.
# to verify foo-1.23.tar.gz using foo-1.23.tar.gz.sha1 # and pubkey.pem openssl dgst -sha1 -verify pubkey.pem -signature foo-1.23.tar.gz.sha1 foo-1.23.tar.gz
Use the enc -base64 option.
# send encoded contents of file.txt to stdout openssl enc -base64 -in file.txt # same, but write contents to file.txt.enc openssl enc -base64 -in file.txt -out file.txt.enc
It's also possible to do a quick command-line encoding of a string value:
$ echo "encode me" | openssl enc -base64 ZW5jb2RlIG1lCg==
Use the -d (decode) option to reverse
the process.
$ echo "ZW5jb2RlIG1lCg==" | openssl enc -base64 -d encode me
You may have occasion to want to encrypt a file without having to build or use an entire key/certificate structure. All you want to have to remember is a password. It can nearly be that simple—if you can also remember the cipher you employed for encryption.
To choose a cipher, consult the enc(1) man page. More simply (and perhaps more accurately), you can ask openssl for a list in one of two ways.
# see the list under the 'Cipher commands' heading openssl -h # or get a long list, one cipher per line openssl list-cipher-commands
After you choose a cipher, you'll also have to decide if you want to base64-encode the data. Doing so will mean the encrypted data can be, say, pasted into an email message. Otherwise, the output will be a binary file.
# encrypt file.txt to file.enc using 256-bit AES in CBC mode openssl enc -aes-256-cbc -salt -in file.txt -out file.enc
Para informação teórica sobre algoritmos de cifragem/decifragem, ver http://www.dei.isep.ipp.pt/~andre/documentos/criptografia.html
# the same, only the output is base64 encoded for, e.g., e-mail openssl enc -aes-256-cbc -a -salt -in file.txt -out file.enc
To decrypt file.enc you or the
file's recipient will need to remember the cipher and the
passphrase.
# decrypt binary file.enc openssl enc -d -aes-256-cbc -in file.enc
# decrypt base64-encoded version openssl enc -d -aes-256-cbc -a -in file.enc
You'll first need to decide whether or not you want to encrypt your key. Doing so means that the key is protected by a passphrase.
On the plus side, adding a passphrase to a key makes it more secure, so the key is less likely to be useful to someone who steals it. The downside, however, is that you'll have to either store the passphrase in a file or type it manually every time you want to start your web or ldap server.
mycert.pem which will
contain both the private key and
the public certificate based on
it. The certificate will be
valid for 365 days, and the key
(thanks to the
-nodes
option) is unencrypted.openssl req \ -x509 -nodes -days 365 \ -newkey rsa:1024 -keyout mycert.pem -out mycert.pem
Using this command-line
invocation, you'll have to
answer a lot of questions:
Country Name, State, City, and
so on. The tricky question is “Common
Name.” You'll want to
answer with the
hostname or CNAME by which
people will address the server.
This is very important. If your
web server's real hostname is
mybox.mydomain.com but
people will be using
www.mydomain.com to
address the box, then use the
latter name to answer the “Common
Name” question.
-subj option.
I've included some
information about
location into the
example that
follows, but the
only thing you
really need to
include for the
certificate to be
useful is the
hostname (CN).nota: a opção -subj não está disponível na versão 0.9.5a do openssl
openssl req -x509 -nodes -days 365 -subj '/C=US/ST=Oregon/L=Portland/CN=www.madboa.com' -newkey rsa:1024 -keyout mycert.pem -out mycert.pem
An
SSL
certificate
contains
a wide
range of
information:
issuer,
valid
dates,
subject,
and some
hardcore
crypto
stuff.
The
x509
subcommand
is the
entry
point
for
retrieving
this
information.
The
examples
below
all
assume
that the
certificate
you want
to
examine
is
stored
in a
file
named
cert.pem.
Using
the
-text
option
will
give you
the full
breadth
of
information.
openssl x509 -text -in cert.pem
Other options will provide more targeted sets of data.
# who issued the cert? openssl x509 -noout -in cert.pem -issuer
# to whom was it issued? openssl x509 -noout -in cert.pem -subject
# for what dates is it valid? openssl x509 -noout -in cert.pem -dates
# the above, all at once openssl x509 -noout -in cert.pem -issuer -subject -dates
# what is its hash value? openssl x509 -noout -in cert.pem -hash
# what is its MD5 fingerprint? openssl x509 -noout -in cert.pem -fingerprint
Use the genrsa option.
# default 512-bit key, sent to standard output openssl genrsa # 1024-bit key, saved to file named mykey.pem openssl genrsa -out mykey.pem 1024 # same as above, but encrypted with a passphrase openssl genrsa -des3 -out mykey.pem 1024
Use the rsa option to produce a
public version of your private RSA key.
openssl rsa -in mykey.pem -pubout
Building DSA keys requires a parameter file, and DSA verify operations are slower than their RSA counterparts, so they aren't as widely used as RSA keys.
If you're only going to build a single DSA key, you can do so
in just one step using the dsaparam
subcommand.
# key will be called dsakey.pem openssl dsaparam -noout -out dsakey.pem -genkey 1024
If, on the other hand, you'll be creating several DSA keys, you'll probably want to build a shared parameter file before generating the keys. It can take a while to build the parameters, but once built, key generation is done quickly.
# create parameters in dsaparam.pem openssl dsaparam -out dsaparam.pem 1024 # create first key openssl gendsa -out key1.pem dsaparam.pem # and second ... openssl gendsa -out key2.pem dsaparam.pem
Perhaps you've grown tired of typing your passphrase every time
your secure daemon starts. You can decrypt your key, removing the
passphrase requirement, using the rsa or
dsa option, depending on the signature
algorithm you chose when creating your private key.
If you created an RSA key and it is stored in a standalone file
called key.pem, then here's how to
output a decrypted version of the same key to a file called
newkey.pem.
# you'll be prompted for your passphrase one last time openssl rsa -in key.pem -out newkey.pem
Often, you'll have your private key and public certificate stored
in the same file. If they are stored in a file called
mycert.pem, you can construct a
decrypted version called newcert.pem
in two steps.
# you'll need to type your passphrase once more openssl rsa -in mycert.pem -out newcert.pem openssl x509 -in mycert.pem >>newcert.pem
Gerar chave publica + privada (ssh-keygen);
Copiar chave publica para $HOME/.ssh/authorized_keys na máquina remota (onde se deseja entrar sem necessidade de login);
Usar mais do que um chave privada;
Usar o ssh-agent.
Last update: 16-02-2005