Deploying Boulder in my machine

I am trying to study boulder(https://github.com/letsencrypt/boulder) in my machine. This is for studying Certificate Authority and boulder to be implemented for our current project in our company.
I am facing issue in getting certificate from boulder using certbot client. The below explains step by step procedures I did

1, Added hostname in /etc/hosts -> 0.0.0.0 www.example.com
2, Started boulder using sudo docker-compose up
3, sudo certbot certonly --standalone -d www.example.com --server http://localhost:4000/directory

After this I am getting below unauthorized error
Domain: www.example.com
Type: unauthorized
Detail: The key authorization file from the server did not match
this challenge
“jMcIS2vo4mZQtX2NiwJ8ZtGnIv9dIcQLJrNeqETstYY.OpMfxcxRo1pl4KT4GbITXwEtBRZfPOxFO9Zcwu9y2S4”
!= “”

I tried changing FakeDNS address to 172.17.0.1(docker ip), which is causing connection refused error.
Please help me solve this case as I am new to certificate authority and boulder

1 Like

I think you were on the right track here. The "connection refused" is probably because Boulder is configured by default to connect to non-standard HTTP/HTTPS ports. You'll want to change them to the standard ports:

$ jq .va.portConfig test/config/va.json
{
  "httpPort": 5002,
  "httpsPort": 5001,
  "tlsPort": 5001
}
1 Like

Thanks for the immediate help. I changed the config to
{
“httpPort”: 80,
“httpsPort”: 443,
“tlsPort”: 5001
}
Then restarted boulder and executed
sudo certbot certonly --standalone -d www.example.com --server http://localhost:4000/directory
Now getting below error

Domain: www.example.com
Type: connection
Detail: During secondary validation: Fetching
http://www.example.com/.well-known/acme-challenge/MLPl4D9RD1WRhjxv5uFNQle-efjtI8opmZrkfB7bu0s:

1 Like

Ah yeah, you need to make the same change to va-remote-a.json and va-remote-b.json.

It seems there have been some big changes to Boulder since I last used it.

2 Likes

Thanks _az. I think its working, I got two files

/etc/letsencrypt/live/www.example.com/fullchain.pem
/etc/letsencrypt/live/www.example.com/privkey.pem

It will be good help if you can provide some info in how to use boulder as CA in intranet with n number of host. I am looking solution for mutual secured communication between host and not browser based
Any help appreciated.
Thanks

1 Like

Well, TLS is certainly a good way to create a system of mutual secure communication.

But Boulder is not a suitable tool for that. Boulder is created specifically to address the needs of a WebPKI CA with millions of subscribers. It is not a good fit for anything else.

There are friendlier tools that can create a private PKI/CA with client certificates and everything you need for mutual secure communication. For example https://github.com/smallstep/certificates (https://smallstep.com/docs/getting-started/) can do all of this for you, and is pretty well documented. It even supports the same ACME protocol as Boulder/Let’s Encrypt, though I’m not sure whether you really need that at all.

The simplest thing:

  • Create your own private PKI/CA with smallstep.
  • Issue some client certificates for each of your hosts, from that CA.
  • Configure each host’s webserver (or any kind of server, doesn’t need to be HTTP) to require TLS client certificate authentication, and verify against the CA certificate. You should be able to find ample examples for Apache or nginx or whatever webserver you use.

and there you go, mutual secure communication! Mould to your needs.

4 Likes

Hi Thanks for the detailed info about small step. It is very simple and it really helped me in understanding lot of things.
In smart step the root key is stored in ~/.step/certs/root_ca.crt. This key I have to install in every host machine in order to trust CA(below code). Am I right

$ sudo cp root-ca.crt /usr/share/ca-certificates/
$ sudo dpkg-reconfigure ca-certificates

I am checking where the root certificate authority key in boulder also. But couldnt find the correct one. Could you please help in this one too?

Thanks

You probably don’t want the entire system to trust the CA certificate. That is potentially quite dangerous.

Say you are trying to create a mutually authenticated secure channel - mutual TLS. The purpose of the CA certificate would be to verify that the host you are talking to has a certificate signed by that CA, and vice-versa. Everybody else is unauthorized.

How you actually configure that comes down to what server software you are using. There are some pretty good examples on this page: https://smallstep.com/hello-mtls . Maybe start with one of the simple examples, like nginx (server) + curl (client).

1 Like

Hi _az thanks for the info.
What I understand is either we need to add CA’s certificate in trust store which in your case is dangerous or we need to add “–cacert” for each request like shown below.

curl --cert client.crt --key client.key --cacert ca.crt https://myserver.internal.net:443

Is my understanding correct?
Thanks

1 Like

Yes. It’s hard to tell if any of this is good advice as you’ve been a bit vague about what you’re trying to do.

2 Likes
curl --cert fullchain.pem --key privkey.pem --cacert ca.crt https://myserver.internal.net:443

Where can I find the root CA certificate in case of boulder to use with above code?

Found the root certificate inside docker container --> /tmp/root-cert-rsa.pem

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.