I am trying to configure boulder for an internal purpose - Issue certificates for internal infra.
successful with a test environment and now i am trying to configure it for a production use
I have done the following changes below as per the documents and red few from community 1. Changes i made in the docker-compose.yml -changed the fake_dns to internal one.
2.Added dns to three alternative we have internally
**3.**Changed dnsResolvers to the internal one - test/config/va.json
**4.**Changed dnsResolvers to the internal one - test/config/va-remote-b.json
**5.**Changed dnsResolvers to the internal one - test/config/va-remote-a.json
Certbot:
version :1.18.0
configured from the source- pip
any lead to that issue ? or help me to setup an initial production version of boulder would be great.am i going thru the right direction ?
you'd better looking for something specifically made for this task.
boulder has a lot of think to config to use in secure way producion, like you need to update GRPC keyset in config files in text/grpc/keyset (keep mind all thoses test key are exposed to public
ex ) /test/grpc-creds/minica-key.pem
and unexpose all those debug ports in config.
Thanks for your reply, but boulder is a requirement and we are planning to move with that.. and sure we need to address all other security concerns accordingly ( i will try use grpc key set from an internal one later) .. but for now i am trying to make it working as an initial production version..
It sounds very much like you destroyed the Boulder database in between attempts, and Certbot is trying to use a an ACME registration that no longer exists in the Boulder database.
Try deleting the relevant directory in /etc/letsencrypt/accounts/ and it will force Certbot to register a new one.
FWIW, I very much agree with @orangepizza. Trying to deploy Boulder is not a good idea; it is not a general purpose CA. Anything else (like Step CA's ACME server) is likely to be a better choice.
Thanks for the tips. and i already have gone thru this document. and that i understood as mentioned below.
I need to do some changes on the docker-compose.yml
fake_dns , dns - I already have done that.
1.Security Context
As i understood that it is described more on network access of specific components. and for sure that i need to do this when i am fully ready to launch the production - but currently just making it work on the internal infra. 2.Inter-Process Communication
Transport Security
yes i need to change this to an internal one instead of minica based TLS, but later, currently this fine for an initial start
Client Permissions
clientNames section in their config. This specifies a list of SANs, of which at least one must be present in the client certificate presented by any client connecting - currently, i am using inbuilt cert then it should be fine for now.
Service discovery
3Database Permissions
Since all the components are running on the same container or same host - the local host
it is fine currently ?. and may be i will change the host name and put the permission accordingly but on later scope.
4.Audit Logging
I have to separate the audit log , i need to do that in the later scope
5.Separation of systemd units
i have to separate the components in to separate systemd service units and manage it separately for any failure happening insted of failing entire boulder - will have to do that in later scope. 5.Ports and DNS
For now.- i have changed the dns to the internal one as i have mentioned in the beginning and mostly my preferred challenge would be http ..
here is my confusion do i need to change anything other than that as i have mentioned in the first question on the topic.
currently, whole i need is to just make it work with my dns and HTTP challenge, for that i am not sure what all other changes i have to make from what i already made ?
This time boulder showing another issue: that is quiet sure ,reason i am using a private domain (TLD) - as i understand that boulder is using a public_suffix_list for the tld validation. just curious does the boulder is loading this list form a locally synchronized list or directly from any pulibc list. is there any way i can add my private TLD and it's rules for an internal use ? do we have any config or local suffix list internally for boulder already ? or do i need to customize it ?
i know i am asking much, sorry that i am making it lengthy already. and thanks for your support.
boulder imports "github.com/weppos/publicsuffix-go/publicsuffix" hereand there (ra.go and iana.go and a few test functions) to fetch suffix list, not sure how it patch public suffix though
If you'd compile Boulder yourself you could modify that dependency quite easily of course, but if you run Boulder from a Docker container, I'm not so sure.. Which of course only strengthens the idea that running Boulder for this application is probably a very bad idea.
I would very much urge the people making this decision to rethink their plan.
If you'd compile Boulder yourself you could modify that dependency quite easily of course, but if you run Boulder from a Docker container, I'm not so sure.
Docker compose are set to mount host-compiled binary to run, so it will run edited code. otherwise it wouldn't be useful as dev envirement
Thanks for the replies : now i could move further with this issue, i have done few modification on the public suffix list fetching (iana.go)- i have loaded the public suffix list form a local file there fore i do have the full control over it, and then i added only needed TLD rules there and then validated my private domain and it worked.
and now i do have another issue in challenge validation
