-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
non tld domains work? #120
Comments
Well, first of all, if your hostname is acme-certmanager.nd.dakota.home, then the domain name is "nd.dakota.home" and not just "dakota.home". The system is doing DNS lookups to look for a CAA record on the domain itself (nd.dakota.home) and if it cannot find one, on the parent domain(s), in your case on dakota.home and then home. Your DNS is not setup properly if the home domain is not defined. The solution is either adding a CAA record in a (sub)domain that does exist in your DNS, or setup the home zone. Also see https://github.com/hakwerk/labca?tab=readme-ov-file#common-error-messages for some tips on these errors and more background on CAA. |
make sense. if i have a root domain dakota.home but i also deploy two sub domains across datacenters like nd.dakota | sd.dakota, does that mean lab-ca needs to be created for only the root domain. I listed all root and subdoamins in my initial whitelist but if thats cause, i dont see a way to roll back my config so i can change the common name and domain whitelist. Is that not possible? Would i need to remove the install and reinstall |
You did correct in including all three values (the root and both sub domains) in the whitelist! If you only added the root domain you would probably hit the ratelimit issue as described in #117 for hosts within the subdomains. You "just" need to take care of the CAA record to make the validation check happy |
sounds good one last question, my domain is on a windows server environment. I stumbled upon a guide to add a CAA entry however it appears to reference a unique record value (see below). Would it be wrong to assume any value would work for lab-ca or lab-ca require a specific value? Add-DnsServerResourceRecord -name your_own_name -RecordData 00056973737565656E74727573742E6E6574 -Type 257 -ZoneName your_zone_name |
The value does matter, it should be the value of the "issuerDomain" from file /home/labca/boulder_labca/config/va.json (or I think in your case you want to end up with this in DNS:
That would say that the issuer on domain nd.dakota.home (in your example the machine acme-certmanager.nd.dakota.home) is allowed to issue certificates for the whole of dakota.home The RecordData is some hex encoded value according to https://serverfault.com/questions/914108/how-to-add-a-caa-record-to-dnsmasq. It seems to always start with 00056973737565 and then using https://cryptii.com/pipes/hex-decoder to replace several values from https://sslmate.com/caa/, I think that in your case the RecordData would be 000569737375656E642E64616B6F74612E686F6D65 or if it should be "dakota.home" instead of "nd.dakota.home" then it would be 0005697373756564616B6F74612E686F6D65 |
thanks so much i was able to install! |
2024-03-26T09:10:21-04:00 acme.sh [Tue Mar 26 09:10:21 EDT 2024] Sleep 10 and retry. i am trying to use an opnsense appliance as the acme-client. The opnsense instance consistently fails to register to labca. Is there any specific external account binding creds (key identifier or hmac key or email address) needed for a client to register to lab ca? |
You'll need to trust the LabCA root certificate first on the opnsense instance. Opnsense tries to communicate with https://acme-certmanager0.dakota.home but the certificate of LabCA is not trusted until you explicitly add it to the opnsense trust store. |
if i had a domain such as dakota.home, would that work with this service?
OOPS
Some unexpected error occurred!
control-1 | Verifying acme-certmanager.nd.dakota.home...
control-1 | Traceback (most recent call last):
control-1 | File "/opt/labca/acme_tiny.py", line 199, in
control-1 | main(sys.argv[1:])
control-1 | File "/opt/labca/acme_tiny.py", line 195, in main
control-1 | signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca, disable_check=args.disable_check, directory_url=args.directory_url, contact=args.contact, check_port=args.check_port)
control-1 | File "/opt/labca/acme_tiny.py", line 153, in get_crt
control-1 | raise ValueError("Challenge did not pass for {0}: {1}".format(domain, authorization))
control-1 | ValueError: Challenge did not pass for acme-certmanager.nd.dakota.home: {'identifier': {'type': 'dns', 'value': 'acme-certmanager.nd.dakota.home'}, 'status': 'invalid', 'expires': '2024-03-18T14:46:01Z', 'challenges': [{'type': 'http-01', 'status': 'invalid', 'error': {'type': 'urn:ietf:params:acme:error:dns', 'detail': "DNS problem: SERVFAIL looking up CAA for home - the domain's nameservers may be malfunctioning", 'status': 400}, 'url': 'http://boulder:4001/acme/chall-v3/1/zAND0Q', 'token': 'rp1CRhAn6YF9CTPHg_jRmYO5FzMRgB0zePt23WN12nY', 'validationRecord': [{'url': acme-certmanager.nd.dakota.home/.well-known/acme-challenge/rp1CRhAn6YF9CTPHg_jRmYO5FzMRgB0zePt23WN12nY', 'hostname': 'acme-certmanager.nd.dakota.home', 'port': '80', 'addressesResolved': ['198.19.155.252'], 'addressUsed': '198.19.155.252', 'resolverAddrs': ['A:198.19.189.86:53', 'AAAA:198.19.189.86:53']}], 'validated': '2024-03-11T14:46:01Z'}]}
ok
The text was updated successfully, but these errors were encountered: