Creating Long Term SSL Certificates
2018-3-12 06:13:0 Author: reusablesec.blogspot.com(查看原文) 阅读量:1 收藏

Creating Long Term SSL Certificates

"It's constantly fascinating for me that something that feels absolutely right one year, 12 months later feels like the wrong thing to do." --Damian Lewis

Often I find myself having to create my own SSL certificates. Be it an internal web-server, or two scripts that need to communicate to each other, SSL is the easiest way to encrypt network traffic. Unfortunately it's also one of the most dangerous encryption methods. If you make a mistake setting it up it usually works ... at least for a little while.

Ignoring the client SSL checks for now, (hint if your script is using SSL and it works the first time, you probably are not checking SSL correctly), one area of danger is having your SSL certificates expire. As an example of that, recently every Oculus Rift broke because a code signing certificate expired. Admittedly this was a different type of certificate, but the same thing tends to happen with internal SSL deployments. People do not remember to update them, and when they expire things tend to break, (at least if your clients are checking SSL properly). The problem is when you use the standard OpenSSL libraries to create your certificates, there's three places that you need to specify certificate lifetimes. If you forget to specify any of the three, the certificate will be valid only for the default which is set to be "365 days".

These lifetime checks are:

  1. The Certificate Authority has an expiration date
  2. The actual certificate you are using has an expiration date
  3. The CA signature for the certificate has an expiration date

Since most stack-overflow posts don't cover this, and Linux man pages are not helpful unless you already know what you are doing, I wanted to share my cheat sheet for creating long term, (valid for one thousand years), SSL Certificate Authorities and signing certs. This script was born from many previous failed efforts, and to be honest I'm still not sure I have it perfectly right. If you notice any improvements that could be made, please let me know! 

Requirements/Comments:

  • These instructions were written for CentOS. It should work for most other Linux flavors without any changes. If you are using Windows, good luck!
  • OpenSSL
  • Whenever you see 365000 in the command that's the expiration date. I'm using 365*1000 as shorthand for one thousand years. Yes I realize that isn't exactly accurate. Feel free to change this to the time period you want to use.
Creating the Certificate Authority:

(If you already have a CA ignore this, but you might want to check the valid lifetime for that CA)

  • Generate the key for the CA using 4096 RSA. Note the key will be cakey.pem so protect that!
openssl req -new -newkey rsa:4096 -nodes -out ca.csr -keyout cakey.pem
  • Create the CA's public certificate which will be called "cacert.pem". Note the '-days' field:
openssl x509 -trustout -signkey cakey.pem -days 365000 -req -in ca.csr -out cacert.pem
Important: When you run the previous command, you'll be set a list of questions. Note, for many SSL deployments you *must* have the Country, City, State, and Organization match between your CA and the certificates you are signing. Does this make sense? Of course not! The domain can be pretty important as well depending on what you are doing.
  • Next you need to copy the CA info and create the required files into where OpenSSL expects them. Yes if you know what you are doing you can override the defaults, but if not here's what to do:
    1. If the /etc/pki/CA directly does not exist, create it
    2. mv cakey.pem /etc/pki/CA/secret/cakey.pem
    3. touch /etc/pki/CA/index.txt
    4. create or edit /etc/pki/CA/serial using the text editor of your choice
    5. In this file put a list of all the serial numbers you want to assign certificates, separated by a newline. For example:
      • 01
      • 02
      • 03
      • 04
    6. It is *highly* recommended that you set permissions on the /etc/pki/CA directory so only the user you want to sign certificates has access to it.
  • Note, cacert.pem is not used for signing SSL certificates, but you'll need to push it to clients that are verifying the certificates

Creating and Signing a SSL Certificate:
  • Create the certificate private key using RSA 4096. It is named client.key in this example. Make sure you protect this!
 openssl genrsa -out client.key 4096
  • Create the certificate request. Note the "days" field.
openssl req -new -key client.key -out client.csr -days 365000  
Important: Remember for the questions it asks you, the Country, City, State, and Organization *must* match between your CA and the certificates you are signing. In addition, the domain can be pretty important depending on if you are checking that with your client or not
  •  Create the actual client certificate. Once again, note the '-days' field
openssl ca -in client.csr -out client.pem -days 365000 -notext

Resulting Files: 
  1. Public Client Certificate: client.pem
  2. Client private key: client.key (Only deploy on the server that owns this key)
  3. Public CA certificate: cacert.pem
  4. Private CA key: cakey.pem (Protect this one!!)

Popular posts from this blog

Tool Deep Dive: PRINCE

Image

Tool Name: PRINCE (PRobability INfinite Chained Elements) Version Reviewed: 0.12 Author: Jens Steube, (Atom from Hashcat) OS Supported: Linux, Mac, and Windows Password Crackers Supported:  It is a command line tool so it will work with any cracker that accepts input from stdin Blog Change History: 1/4/2015: Fixed some terminology after talking to Atom 1/4/2015: Removed a part in the Algorithm Design section that talked about a bug that has since been fixed in version 0.13 1/4/2015: Added an additional test with PRINCE and JtR Incremental after a dictionary attack 1/4/2015: Added a section for using PRINCE with oclHashcat Brief Description:   PRINCE is a password guess generator and can be thought of as an advanced Combinator attack . Rather than taking as input two different dictionaries and then outputting all the possible two word combinations though, PRINCE only has one input dictionary and builds "chains" of combined words. These chains can have 1 to N wo

More Password Cracking Tips: A Defcon 2022 Crack Me If You Can Roundup

Image

 “We do not learn from experience... we learn from reflecting on experience.”   -- John Dewey Introduction: KoreLogic's Crack Me if You Can (CMIYC) is one of the oldest as most established password cracking competitions. Held every year at Defcon, it serves as a great way to pull together password enthusiasts from all over the world and provides a shared use-case that drives password cracking tool development throughout the rest of the year. This year I competed as a street team and managed to finish in 12th place: Now that I've had a week to look back on things, there certainly are strategies where I could have done better. The first is with my cracking setup. I had two systems I used. My primary cracking system was still my laptop running an Ubuntu VM utilizing WSL on a Windows 11 install. My secondary system was the computer I described setting up in this blog post . Primary Laptop: CPU: i7-8640U CPU RAM: 16 GB Storage: 500GB SSD   Desktop Computer: CPU: Intel i5-7600k, 1 p

The RockYou 32 Million Password List Top 100

But first, a quick responses to one of the previous comments, (since it really did merit a front-page post). Tfcx posted: The initial vulnerability was posted 29th November on a hacking forum called darkc0de here: http://forum.darkc0de.com/index.php?action=vthread&forum=11&topic=13082 Thanks, as that really helps narrow down the timeframe, (and reading that post and related posts was interesting if a bit depressing). The hack itself appears pretty straightforward once you see it, (like most things once the solution is presented to you it's easy, but finding it in the first place is hard). I'm still interested in the hacker Igigi, and have been tossing about all sorts of theories; but I'll refrain from posting them here since they are all pure WAGs right now. Now on to the main topic: Per Thorsheim wrote: I would like to see a comparison of Twitters 370 banned passwords against the top 370 or so passwords stolen from rockyou (http://www.techcrunch.com/2009/12/27/twi


文章来源: https://reusablesec.blogspot.com/2018/03/creating-long-term-ssl-certificates.html
如有侵权请联系:admin#unsafe.sh