Intermediate server config? Guide?

[Rapt88]

hi,

do you have any documentation on configuring an intermediate authority server, so I can turn the CA off? I have a feeling I know how this is done, but would love to follow a guide if there is one.

[dopey]

Hey @Rapt88, I'm not sure I understand what you're asking. Can you elaborate? Maybe an example would help me understand. I also have a feeling we can do this, just don't quite understand the use case.

[Rapt88]

Hi @dopey

I'll try and elaborate, let me know if you need more info.

1. I have three groups of servers. On three different networks.
2. I want each group of servers to have an intermediate authority (IA) server, issuing certificates. (server cert can be 1 week, then renew etc)
3. I want a single certificate authority (CA) that has a lifespan of 20 years, which will only create certificates for the IAs (lifespan 10 years).

I will therefore have 1 x CA (mostly offline), 3 x IA's (always online), ? x number of server certificates.

Now from my understanding the CA will use a self signed certificate (one it creates itself), but the IA should be created with a certificate made from the CA.

Q: How do I create the IA from an already created certificate + key? _
(maybe an easier way to ask this question is how do I make a CA with an existing cert and key?)_

Notes: I think it's as simple as using the "[–root=path] [–key=path]" in the step ca init, but wanted to double check.

Hopefully this makes sense. A similar diagram of what I'm trying to achieve is in this following link.
https://www.sysadmins.lv/content/images/pages/1351/pki-hierarchy.png

Thanks in advance, and have a nice weekend.

[Rapt88]

I'm a little lost here to be honest. I've provisioned the following.

1 x primary Certificate authority (CA), which is running fine. I can create and renew certificates against it.
1 x basic webserver (end entity), and I can request and renew certificates from the certificate authority to this.

I have then proceeded to provision an intermediate certificate authority (IA), using the following information I have found in the gitter channel, and what you have said above. the IA step ca stands up and runs fine, but I get the following errors when trying to create certificates against it.

step ca
2020/10/08 14:11:11 /home/travis/.gimme/versions/go1.14.7.linux.amd64/src/net/http/server.go:3088: http: TLS handshake error from ...:56848: remote error: tls: bad certificate

terminal request for certificate
~/pki/certificates$ step ca certificate ...:443 test.crt test.key
client GET https://.../provisioners?limit=100 failed: Get "https://.../provisioners?limit=100": x509: too many intermediates for path length constraint

I did also notice that Max (Dopey) posted the following almost one year ago, is this still valid? and could this be the cause of my issues here? (creating cert for CA, and then using CA cert to create IA cert, which then signs cert for end entity... too many in the chain?)

Max @dopey Nov 22 2019 21:13
@bonedaddy If you look at the configuration file used by step-ca, you’ll see where the root and intermediate are defined ($(step path)/config/ca.json). There are no stipulations beyond the root being the certificate that signed the intermediate and that the path len on the root cert be at least 1 (so you can use an intermediate. You could replace those files with your own root and intermediate (or intermediate and sub-intermediate) and step-ca will still work.
The unfortunate problem is that currently you won’t be able to use step to generate that root, intermediate, and sub intermediate. For two reasons: 1) The max path len on any step generated root cert is hardcoded to 1, meaning you can only have one intermediate in a valid chain. 2) step cannot currently create CSRs for anything except leaf certificates.
So you’ll likely have to use openssh to create your initial PKI, but once you have the intermediate and sub-intermediate you should be able to just adjust the step-ca config file to point to those certs (and the private key for the sub-intermediate), and the architecture should work as you’d like.

[tashian]

Hi @Rapt88,

OK, so as I understand it, you're trying to have two intermediates in your chain. You will need to use certificate templates and re-create your root CA so that those certs have longer path lengths. Since @dopey wrote that comment in 2019, we have added support for certificate templates, which make longer chains possible.

Here's a tutorial for how to make a longer intermediate CA chain:
https://smallstep.com/blog/x509-certificate-flexibility/#example-intermediate-ca-chain

Does this help?

Carl

[Rapt88]

Hi Tashian,

That link helped. I had to go off track a little on it to get what I want working, but do now have 1 CA which provisions a certificate to be used on a second server acting as an IA, which can now provision certificates for end entities. This means I can turn off the CA and keep making certs, which minimizes the risk across the proposed infrastructure.

Now I need to figure out how I just did what I did, so I can repeat the steps =)

Thanks. I think we can close this discussion now.

[bonedaddy]

@Rapt88 would you mind replying to this issue with your solution once you have it? I've been also looking to do the same thing

[Rapt88]

Hi @bonedaddy,

I'm undecided regarding the best approach for this, but what I did was as follows.

Server 1 needed a root.crt (1) and an intermediate.crt (2)
Server 2 needed a cert for it's root (3), lets call this intermediate2.crt (3) and an intermediate.crt (4)

I made therefore made templates for...

• (1) root.crt (root template)
• (2) Intermediate.crt (intermediate template)
• (3) Intermediate2.crt (intermediate 2 template).

_ Information gained from here... "https://smallstep.com/blog/x509-certificate-flexibility/#example-intermediate-ca-chain" @tashian thanks._

After making the templates, I did the following..

A. Made the root cert and key
step certificate create --template root.tpl
"Acme Corporation Root CA" root_ca.crt root_ca_key

B. Used the root cert and key to make the intermediate (2) cert and key.
step certificate create --template intermediate.tpl
--ca root_ca.crt --ca-key root_ca_key
"Acme Corporation Intermediate CA" intermediate_ca.crt intermediate_ca_key

C. Used the intermediate (2) cert and key to make the intermediate (3) cert and key.
step certificate create --template intermediate2.tpl
--ca intermediate_ca.crt --ca-key intermediate_ca_key
"Acme Corporation Intermediate 2 CA" intermediate2_ca.crt intermediate2_ca_key

D. I then used the intermediate (3) cert and key to provision the sub certificate authority, using the init command. In doing so this created the 4th intermediate certificate and key that is signing all of the certificates, from that specific certificate authority.

Note: I started with a pathlength of 5 on the root cert, then moved to 4 for the int2 cert and then to 3 for the int3 cert, which gave me plenty of scope, but this is just me playing around to get things working. I'd make sure you use the correct path lengths for what you need.

Note2: This may not be the best practice for doing such infrastructure, but it is the way I achieved this. I found that if I followed the article the way it was wrote, I was getting errors when coming to create the end entity certificates, which is why I created the third template.

I hope this helps.