{"id":1240,"date":"2016-09-10T14:55:16","date_gmt":"2016-09-10T19:55:16","guid":{"rendered":"http:\/\/www.nathanhunstad.com\/blog\/?p=1240"},"modified":"2016-09-10T14:55:16","modified_gmt":"2016-09-10T19:55:16","slug":"pki-revisited","status":"publish","type":"post","link":"https:\/\/www.nathanhunstad.com\/blog\/2016\/09\/pki-revisited\/","title":{"rendered":"PKI Revisited"},"content":{"rendered":"<p>A little more than two years ago, I set up a PKI and <a href=\"http:\/\/www.nathanhunstad.com\/blog\/2014\/08\/setting-up-a-pki\/\" target=\"_blank\">did a post on it<\/a>. The main goal was to get a certificate on my EdgeOS router to get proper HTTPS support without the annoying red X. When I did it, however, I didn\u2019t do it quite right, and so I decided to redo it all. Some of the major problems:<\/p>\n<ul>\n<li>The cert for my router expired after two years. Hence, I as of today I need a new cert anyway.<\/li>\n<li>The intermediate cert also expired after two years. Lame!<\/li>\n<li>To trust the chain, I had to import the intermediate cert into Windows, not the root cert. I should just need the root cert.<\/li>\n<\/ul>\n<p>So I decided to do it right, and do it all over again for posterity, again largely following <a href=\"http:\/\/blog.didierstevens.com\/2008\/12\/30\/howto-make-your-own-cert-with-openssl\/\" target=\"_blank\">this post<\/a> from Didier Stevens and again having the same old issues. Details below.<\/p>\n<p><!--more--><\/p>\n<p>I started basically from scratch, keeping only the root CA key. From this key, I created a root cert that expires after 30 years. I did this because I noticed that most of the root certs out there have pretty lengthy expiration periods. So I ran this command to create a new CA certificate:<\/p>\n<p><span style=\"font-family: 'Courier New';\">openssl req -new -sha256 -x509 -days 10957 -key ca.key -out ca.crt<\/span><\/p>\n<p>Next was creating the intermediate certificate. Remember when I had the problems with creating an intermediate certificate that was allowed to sign things last time? Yup, did it again this time. Eventually, though, I figured it out and ran the following commands, starting with my old IA key:<\/p>\n<p><span style=\"font-family: 'Courier New';\">openssl req -new -sha256 -key ia.key -out ia.csr<\/span><br \/>\n<span style=\"font-family: 'Courier New';\">openssl x509 -sha256 -req -days 5478 -in ia.csr -CA ca.crt -CAkey ca.key -extfile .\/v3.ext -set_serial 2 -out ia.crt<\/span><\/p>\n<p>Fortunately, I found my old ext file from the last time I did it, which provided the intermediate certificate with the proper signing rights. My v3.ext file is as so:<\/p>\n<p><span style=\"font-family: 'Courier New';\">authorityKeyIdentifier=keyid,issuer<br \/>\nbasicConstraints=CA:TRUE<br \/>\nkeyUsage=critical, digitalSignature, nonRepudiation, keyCertSign<\/span><\/p>\n<p>The intermediate certificate is good for 15 years, so I can sign multiple iterations of the server keys with it. I set the serial number as 2 because hey, it\u2019s my second intermediate cert!<\/p>\n<p>Finally, I created the cert for my EdgeOS router:<\/p>\n<p><span style=\"font-family: 'Courier New';\">openssl req -new -sha256 -key erl1.key -out erl1.csr<\/span><br \/>\n<span style=\"font-family: 'Courier New';\">openssl x509 -sha256 -req -days 1096 -in erl1.csr -CA ia.crt -CAkey ia.key -set_serial 3 -out erl1.crt<\/span><\/p>\n<p>To get the right format for the router, I had to cat private key and the certificate together:<\/p>\n<p><span style=\"font-family: 'Courier New';\">cat erl1.crt erl1.key &gt; server.pem<\/span><\/p>\n<p>I then copied both the intermediate certificate and the <span style=\"font-family: 'Courier New';\">server.pem<\/span> file to the router. Why the intermediate certificate as well? So it could send the chain properly. After doing some research into lighttpd, I found that in order to get proper validation, you have to send not only the server certificate, but the intermediate certificate as well. To do this, I modified the <span style=\"font-family: 'Courier New';\">\/etc\/lighttpd\/conf-enabled\/10-ssl.conf<\/span> file to contain the following section:<\/p>\n<p><span style=\"font-family: 'Courier New';\">$SERVER[&#8220;socket&#8221;] == &#8220;0.0.0.0:443&#8221; {<br \/>\nssl.engine\u00a0 = &#8220;enable&#8221;<br \/>\nssl.use-sslv3 = &#8220;disable&#8221;<br \/>\nssl.ca-file = &#8220;\/etc\/lighttpd\/intermediate.crt&#8221;<br \/>\nssl.pemfile = &#8220;\/etc\/lighttpd\/server.pem&#8221;<br \/>\nssl.cipher-list = &#8220;aRSA+HIGH !3DES +kEDH +kRSA !kSRP !kPSK !NULL !RC4&#8221;<\/span><\/p>\n<p>Although the <span style=\"font-family: 'Courier New';\">ssl.pemfile<\/span> variable was already correctly set, I had to add the <span style=\"font-family: 'Courier New';\">ssl.ca-file<\/span> variable to point at the intermediate certificate.<\/p>\n<p>But wait! There is this ominous warning at the top of the <span style=\"font-family: 'Courier New';\">\/etc\/lighttpd\/conf-enabled\/10-ssl.conf<\/span> file:<\/p>\n<p><span style=\"font-family: 'Courier New';\"># Do not edit, auto generated by ubnt-gen-lighty-conf.sh<\/span><\/p>\n<p><span style=\"font-family: Arial;\">So it would appear that upon reconfig the <span style=\"font-family: 'Courier New';\">ssl.ca-file<\/span> setting would not be preserved. So the solution is to edit the <span style=\"font-family: 'Courier New';\">ubnt-gen-lighty-conf.sh<\/span> file so that the <span style=\"font-family: 'Courier New';\">10-ssl.conf<\/span> file is recreated properly.<\/span><\/p>\n<p>Finally, I exported the root CA into a format that I could import into Windows, so that anything signed by my root CA would be trusted.<\/p>\n<p><a href=\"http:\/\/www.nathanhunstad.com\/blog\/wp-content\/uploads\/2016\/09\/image-1.png\"><img loading=\"lazy\" decoding=\"async\" style=\"background-image: none; padding-top: 0px; padding-left: 0px; display: inline; padding-right: 0px; border: 0px;\" title=\"image\" src=\"http:\/\/www.nathanhunstad.com\/blog\/wp-content\/uploads\/2016\/09\/image_thumb-1.png\" alt=\"image\" width=\"633\" height=\"282\" border=\"0\" \/><\/a><\/p>\n<p>When all of this was said and done, I got the happy green lock in Chrome!<\/p>\n<p><a href=\"http:\/\/www.nathanhunstad.com\/blog\/wp-content\/uploads\/2016\/09\/image-2.png\"><img loading=\"lazy\" decoding=\"async\" style=\"background-image: none; padding-top: 0px; padding-left: 0px; display: inline; padding-right: 0px; border: 0px;\" title=\"image\" src=\"http:\/\/www.nathanhunstad.com\/blog\/wp-content\/uploads\/2016\/09\/image_thumb-2.png\" alt=\"image\" width=\"387\" height=\"432\" border=\"0\" \/><\/a><\/p>\n<p><a href=\"http:\/\/www.nathanhunstad.com\/blog\/wp-content\/uploads\/2016\/09\/image-3.png\"><img loading=\"lazy\" decoding=\"async\" style=\"background-image: none; padding-top: 0px; padding-left: 0px; display: inline; padding-right: 0px; border: 0px;\" title=\"image\" src=\"http:\/\/www.nathanhunstad.com\/blog\/wp-content\/uploads\/2016\/09\/image_thumb-3.png\" alt=\"image\" width=\"384\" height=\"481\" border=\"0\" \/><\/a><\/p>\n<p><a href=\"http:\/\/www.nathanhunstad.com\/blog\/wp-content\/uploads\/2016\/09\/image-4.png\"><img loading=\"lazy\" decoding=\"async\" style=\"background-image: none; padding-top: 0px; padding-left: 0px; display: inline; padding-right: 0px; border: 0px;\" title=\"image\" src=\"http:\/\/www.nathanhunstad.com\/blog\/wp-content\/uploads\/2016\/09\/image_thumb-4.png\" alt=\"image\" width=\"381\" height=\"478\" border=\"0\" \/><\/a><\/p>\n<p>The end result was exactly what I wanted: a certificate for my router with a three-year lifespan, signed by the intermediate cert, which is signed by my trusted root certificate.<\/p>\n<p>At least now when this certificate expires in three years, I\u2019ll be able to replace it no problem and keep the trust chain intact.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>A little more than two years ago, I set up a PKI and did a post on it. The main goal was to get a certificate on my EdgeOS router to get proper HTTPS support without the annoying red X. When I did it, however, I didn\u2019t do it quite right, and so I decided&hellip; <a class=\"more-link\" href=\"https:\/\/www.nathanhunstad.com\/blog\/2016\/09\/pki-revisited\/\">Continue reading <span class=\"screen-reader-text\">PKI Revisited<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[127,19],"tags":[260,251,259],"class_list":["post-1240","post","type-post","status-publish","format-standard","hentry","category-security","category-tech-2","tag-certificates","tag-edgeos","tag-pki","entry"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/posts\/1240","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/comments?post=1240"}],"version-history":[{"count":2,"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/posts\/1240\/revisions"}],"predecessor-version":[{"id":1242,"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/posts\/1240\/revisions\/1242"}],"wp:attachment":[{"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/media?parent=1240"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/categories?post=1240"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/tags?post=1240"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}