<p>Normally when I need to make a CSR, I would use <code>openssl</code> to generate one like you'll see all over the internet:</p>
<pre><code class="language-bash">openssl req -new -key example.com.key -out example.com.csr
</code></pre>
<p>This generates a CSR and asks you to provide the Common Name (URL) of your site.</p>
<p>Recently I've noticed that certs from the above CSR don't work.
From some research, Chrome's version 58 (2017) is when it changed, so I guess it took me a while to catch on.</p>
<p>Using the CommonName (CN) instead of SubjectAltName (SAN) in your cert was deprecated in RFC 2818 (forever ago).
For a long time for browsers didn't enforce that requirement and could fall back to CN, but it seems like that allows homograph attacks
(fake "a" in apple.com, for instance), where the SAN field somehow does not.</p>
<p>Even if you add and trust the issuing and root CA certs, Chrome will still throw <code>ERR_CERT_COMMON_NAME_INVALID</code>.</p>
<p>Generating a CSR with a SAN is not intuitive. Unless you want to use heredoc, you need to create a file first.</p>
<ul>
<li>The <code>req_distinguished_name</code> values set the prompts during the CSR questionairre.</li>
<li>The DNS.x values are the SAN entries. If you have one URL, then commonName and DNS.1 will match, and you'll have no others (no DNS.2, ect).</li>
</ul>
<p><code>vi san.ini</code></p>
<pre><code>[ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
req_extensions     = req_ext

[ req_distinguished_name ]
C = Country Name (2 letter code)
ST = State or Province Name (full name)
L = Locality Name (eg, city)
O = Organization Name (eg, company)
OU = Organization Unit (eg, IT)
CN = Common Name (server FQDN)

[ req_ext ]
subjectAltName = @alt_names

[alt_names]
DNS.1 =
DNS.2 =
DNS.3 =
</code></pre>
<p>Now with this file and your private key in hand, you can create your CSR:</p>
<pre><code class="language-bash"># Set the name of your domain
domain=
# Generate the private key and CSR
openssl req -new -newkey rsa:2048 -nodes -keyout $domain.key -out $domain.csr -config san.ini
</code></pre>
<p>Check your work:</p>
<pre><code class="language-bash">openssl req -in $domain.csr -noout -text
</code></pre>
<p>That's it. Send the CSR off to the CA admin or whoever carves out your certificates.</p>


<h1>Getting the certificate</h1>
<p>So far as I can tell, certbot works in the following way:</p>
<ol>
<li>Certbot is executed from the web-server CLI, and told to download a cert for
an FQDN. Let's say it's getting a cert from <code>example.com</code>.</li>
<li>Certbot opens up a port, I think 443, and listens for requests from the
LetsEncrypt service.</li>
<li>Certbot calls out to LetsEncrypt's service, letting the service know it's
listening on <code>example.com</code> and ready to prove it owns that domain.</li>
<li>LetsEncrypt sends some secret, or maybe collects some secret from the
listening certbot service, proving that certbot's server does indeed own
this domain name.</li>
<li>LetsEncrypt signs a cert and makes it available. Certbot downloads the cert
to the local server.</li>
</ol>
<h2>Configure DNS</h2>
<p>First, ensure that your DNS A record, such as <code>example.com</code>, resolves to
the IP address your server is using. This needs to be an internet accessible
IP address, not an internal RFC-1918 address.</p>
<h2>Install Certbot</h2>
<p>This guide assumes you're using Ubuntu Server.</p>
<pre><code class="language-bash">add-apt-repository ppa:certbot/certbot
apt-get update
apt-get install certbot
</code></pre>
<h2>Download the certificate</h2>
<p>Set the <code>site</code> variable here to your DNS entry which will point to this server.</p>
<pre><code class="language-bash">site="example.com"
certbot certonly --standalone --preferred-challenges http -d $site
</code></pre>
<h2>Use the certificate</h2>
<p>You can find the certificates as files on your server.</p>
<pre><code class="language-bash">> cd /etc/letsencrypt/live/$site
README  cert.pem  chain.pem  fullchain.pem  privkey.pem
</code></pre>
<p>Copy these certs to your web service and use them like any other cert.</p>
<p>Note that if you want to use these certs for HAProxy, you need to combine
<code>cert.pem</code> and <code>privkey.pem</code> into a single file.</p>
<pre><code class="language-bash">cat cert.pem privkey.pem > haproxy-$site.pem
</code></pre>


<p><strong>Note:</strong> This is usually a bad idea. You should really get the team who runs
the CA to send you the certificate in case some <em>bad guy</em> is doing the MITM and
not the local security team. Use this procedure with caution.</p>
<hr>
<h1>Get the signing certificate</h1>
<p>Use <code>openssl</code> to print the certificate data.</p>
<pre><code class="language-bash">openssl s_client -connect google.com:443 -showcerts
</code></pre>
<p>In the output you'll see, among other things, some certificates.
They look like this:</p>
<pre><code class="language-text">-----BEGIN CERTIFICATE-----
blaBLAbla
-----END CERTIFICATE-----
</code></pre>
<p>Find the one signed by your local CA. Copy and paste it into a new file,
such as <code>example.com.crt</code>. The <code>.crt</code> file extension is required.
Don't copy anything before or after the BEGIN and END lines.</p>
<hr>
<h1>Trust the certificate</h1>
<p>As root, move the certificate file to <code>/usr/local/share/ca-certificates</code>,
then run <code>update-ca-certificates</code>.</p>
<pre><code class="language-bash">mv example.com.crt /usr/local/share/ca-certificates
update-ca-certificates
</code></pre>
<p>That's it. Now your system will trust certs signed by that CA too.</p>


Kyle Pericak

"It works in my environment"

Categories

Tags