Posts Tagged ‘private key’

Converting .crt .cer .der to PEM, converting .PEM to .DER and convert .PFX PKCS#12 (.P12) to .PEM file using OpenSSL

Friday, September 1st, 2017

openssl_check_verify_crt_csr_key_certificate_consistency-with-openssl-command-openssl-logo

These commands allow you to convert certificates and keys to different formats to make them compatible with specific types of servers or software. For example, you can convert a normal PEM file that would work with Apache to a PFX (PKCS#12) file and use it with Tomcat or IIS.

  • Convert a DER file (.crt .cer .der) to PEM

     

    openssl x509 -inform der -in certificate.cer -out certificate.pem
    
  • Convert a PEM file to DER

     

    openssl x509 -outform der -in certificate.pem -out certificate.der
    
  • Convert a PKCS#12 file (.pfx .p12) containing a private key and certificates to PEM

     

    openssl pkcs12 -in keyStore.pfx -out keyStore.pem -nodes


    You can add -nocerts to only output the private key or add -nokeys to only output the certificates.

  • Convert a PEM certificate file and a private key to PKCS#12 (.pfx .p12)

     

    openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key \
    -in certificate.crt -certfile CACert.crt

Share this on

Using rsync to copy / synchronize files or backups between Linux / BSD / Unix servers

Monday, November 21st, 2011

Rsync and Rsync over ssh logo picture

Many of us have already taken advantage of the powerful Rsync proggie, however I'm quite sure there are still people who never used rsync to transfer files between servers.. That's why I came with this small post to possibly introduce rsync to my blog readers.
Why Rsync and not Scp or SFTP? Well Rsync is designed from the start for large files transfer and optimized to do the file copying job really efficient. Some tests with scp against rsync will clearly show rsync's superiority.
Rsync is also handy to contiue copying of half copied files or backups and thus in many cases saves bandwidth and machine hdd i/o operations.

The most simple way to use rsync is:

server:~# rsync -avz -e ssh remoteuser@remotehost:/remote/directory /local/directory/

Where remoteuser@remotehost — is the the username and hostname of remote server to copy files to.
/remote/directory — is the directory where the rsync copied files should be stored
/local/directory — is the local directory from which files will be copied to remote directory

If not a preliminary passwordless ssh key (RSA / DSA) authentication is configured on remote server, the above command will prompt for a password otherwise the rsync will start doing the transfer.

If one needs to have a RSA or DSA (public / private key) passwordless SSH key authentication , a RSA key first should be generated and copied over to the remote server, like so:

server:~# ssh-keygen -t dsa
...
server:~# ssh-copy-id -i ~/.ssh/id_dsa.pub root@remotehost
...

That's all folks, enjoy rsyncing 😉

Share this on

How to renew self signed QMAIL toaster and QMAIL rocks expired SSL pem certificate

Friday, September 2nd, 2011

qmail_toaster_logo-fix-qmail-rocks-expired-ssl-pem-certificate

One of the QMAIL server installs, I have installed very long time ago. I've been notified by clients, that the certificate of the mail server has expired and therefore I had to quickly renew the certificate.

This qmail installation, SSL certificates were located in /var/qmail/control under the names servercert.key and cervercert.pem

Renewing the certificates with a new self signed ones is pretty straight forward, to renew them I had to issue the following commands:

1. Generate servercert encoded key with 1024 bit encoding

debian:~# cd /var/qmail/control
debian:/var/qmail/control# openssl genrsa -des3 -out servercert.key.enc 1024
Generating RSA private key, 1024 bit long modulus
...........++++++
.........++++++
e is 65537 (0x10001)
Enter pass phrase for servercert.key.enc:
Verifying - Enter pass phrase for servercert.key.enc:

In the Enter pass phrase for servercert.key.enc I typed twice my encoded key password, any password is good, here though using a stronger one is better.

2. Generate the servercert.key file

debian:/var/qmail/control# openssl rsa -in servercert.key.enc -out servercert.key
Enter pass phrase for servercert.key.enc:
writing RSA key

3. Generate the certificate request

debian:/var/qmail/control# openssl req -new -key servercert.key -out servercert.csr
debian:/var/qmail/control# openssl rsa -in servercert.key.enc -out servercert.key
Enter pass phrase for servercert.key.enc:writing RSA key
root@soccerfame:/var/qmail/control# openssl req -new -key servercert.key -out servercert.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:UK
State or Province Name (full name) [Some-State]:London
Locality Name (eg, city) []:London
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
Organizational Unit Name (eg, section) []:My Org
Common Name (eg, YOUR name) []:
Email Address []:admin@adminmail.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

In the above prompts its necessery to fill in the company name and location, as each of the prompts clearly states.

4. Sign the just generated certificate request

debian:/var/qmail/control# openssl x509 -req -days 9999 -in servercert.csr -signkey servercert.key -out servercert.crt

Notice the option -days 9999 this option instructs the newly generated self signed certificate to be valid for 9999 days which is quite a long time, the reason why the previous generated self signed certificate expired was that it was built for only 365 days

5. Fix the newly generated servercert.pem permissions debian:~# cd /var/qmail/control
debian:/var/qmail/control# chmod 640 servercert.pem
debian:/var/qmail/control# chown vpopmail:vchkpw servercert.pem
debian:/var/qmail/control# cp -f servercert.pem clientcert.pem
debian:/var/qmail/control# chown root:qmail clientcert.pem
debian:/var/qmail/control# chmod 640 clientcert.pem

Finally to load the new certificate, restart of qmail is required:

6. Restart qmail server

debian:/var/qmail/control# qmailctl restart
Restarting qmail:
* Stopping qmail-smtpd.
* Sending qmail-send SIGTERM and restarting.
* Restarting qmail-smtpd.

Test the newly installed certificate

To test the newly installed SSL certificate use the following commands:

debian:~# openssl s_client -crlf -connect localhost:465 -quiet
depth=0 /C=UK/ST=London/L=London/O=My Org/OU=My Company/emailAddress=admin@adminmail.com
verify error:num=18:self signed certificate
verify return:1
...
debian:~# openssl s_client -starttls smtp -crlf -connect localhost:25 -quiet
depth=0 /C=UK/ST=London/L=London/O=My Org/OU=My Company/emailAddress=admin@adminmail.com
verify error:num=18:self signed certificate
verify return:1
250 AUTH LOGIN PLAIN CRAM-MD5
...

If an error is returned like 32943:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:607: this means that SSL variable in the qmail-smtpdssl/run script is set to 0.

To solve this error, change SSL=0 to SSL=1 in /var/qmail/supervise/qmail-smtpdssl/run and do qmailctl restart

The error verify return:1 displayed is perfectly fine and it's more of a warning than an error as it just reports the certificate is self signed.

Share this on

Auto insert password for a Trusted SSL Certificate / Automatically enter password for an SSL Certificate during Apache startup on Debian Lenny

Friday, March 26th, 2010

Protect-Your-Private-SSL_keys-Apache-howto
I've recently installed a Trusted certificate that I've previously protected with a pass-phrase to an Apache server running on top of Debian in order to have a better security.
Now everytime I restart Apache it's pretty annyoing and non-practical at the same time, to enter the Passphrase assigned to the SSL certificate.
It's also dangerous because if Apache crashes and tries to resurrect itself restartig it might not start-up again.
Another unpleasant possible scenario is if for example some of the php code developers tries to change something minor in some Virtualhost and afterwards restarts Apache for the new configurations to take place, again Apache won't bring up and a chaos would emerge.
So I decided to configurate my Apache that it auto fills in the passphrase each time it's being started or restarted.To do that I consulted some online resources and I end up redirected by a blog post to the mod_ssl ssl_reference web page

There is plenty of stuff on that document however in my case all I needed was one directive in /etc/apache2/mods-avalable/mods-available/ssl.conf :

SSLPassPhraseDialog exec:/etc/apache2/mods-available/passphrase

The above code must replace:

SSLPassPhraseDialog builtin

Now last step is to prepare the /etc/apache2/mods-available/passphrase .
Make sure the file has the following content:

#!/bin/sh
echo "yoursecretpassword"

Change above yoursecretpassword with your configured passphrase.
Also please make sure /etc/apache2/mods-availabe/passphrase has proper set permissions. In my case I've set the following permissions for the file:

debian:~# chown www-data:www-data /etc/apache2/mods-available/passphrase
debian:~# chmod 700 /etc/apache2/mods-available/passphrase

That should be it, Restart Apache and make sure Apache is properly loaded without anySSL passphrase prompts.
However you should have in mind that auto enabling passphrase loading on starting in Apache is much more insecure than typing in the password every time you restart Apache. Storing the passphrase in a file is quite insecure compared to if you type it every time Apache starts.
For instance if a hacker breaks into your server he might be able to steal your SSL certificate as well as the passphrase file.
And surely this is something you don't want. Anyways flexibility has a price and if you decide to go the way described, please note the risk first.

 

   

If you haven't already added a password to your private key during certficate generation time,

Of course you can add/remove a passphrase at a later time.

    add one (assuming it was an rsa key, else use dsa)

    openssl rsa -des3 -in your.key -out your.encrypted.key
    mv your.encrypted.key your.key

    the -des3 tells openssl to encrypt the key with DES3.

    remove it

    openssl rsa -in your.key -out your.open.key

    you will be asked for your passphrase one last time
    by omitting the -des3 you tell openssl to not encrypt the output.

    mv your.open.key your.key

 

Share this on