i've already tried win-acme, but i don't have the token from well-know-challenge. it seems that to get it i need certbot anyway. i'll look about Certify The Web as you said, but the way i found is create a virtual machine with ubuntu to continue this process
That domain name is already used by your Vercel app.
What URL will you use to contact your IoT app? It can't be the same name as it will have a different IP address. webprofusion suggested using a different subdomain to address your IoT and maybe even use a DNS Challenge.
But, yes, you can get a cert using a DNS Challenge or an HTTP Challenge. Various ACME Clients support a standalone listener for HTTP Challenge. A web server like IIS is not required. See more about challenges at this link
I realize you want to just get a cert quickly so you can continue with your remaining work. But, setting up your cert issuance and renewal is an essential part. Having secure comms takes some care to get right.
Apart from getting your first cert you need to be sure you can repeat this and update your IoT app every 60 days. Let's Encrypt certs only last for 90 days and renewal after 60 is recommended. You should also have a fallback plan in case something dramatic happens with Let's Encrypt certs.
3 Likes
You are not trying to get a certificate for your website domain, you are trying to get a certificate for your IoT device service.
You need to step back and take the time to understand whats going on. Your home computer is not running the habitatdigital.com.br website, vercel is (on their own machines) so you will not be able to use HTTP challenges to get your certificate. Ignore your website and it's certificate, your website is not the problem.
Your IoT board hosted service needs it's own DNS name (as per my example above or <something>.habitatdigital.com.br, a subdomain/hostname of your own choosing). You cannot refer to your IoT service using an IP address alone, it needs a DNS name to get a valid certificate. That's because you cannot get a certificate for an IP address, it must be for a DNS name.
The reason it works locally and not via your website is that the browser is enforcing it's security policy which is designed to protect people using sites on the public internet. To comply with the browser security policy you need working DNS names and valid certificates.
To get a cert for your device service using Certify The Web (which I develop) I would suggest trying the acme-dns option, this helps you use DNS validation when your DNS provider does not support automation:
- Pick a name for your IoT service. It can be any subdomain .e.g
api.habitdigital.com.br. On the Identifiers tab, removehabitatdigital.com.br and www.baitatdigital.com.brfrom the list of identifiers to include, and add the new name you want. - on the Authorization tab, choose Challenge Type: dns-01 instead of http-01.
- set DNS Update Method to acme-dns DNS API. Leave the other settings as the defaults.
- click Request Certificate. On the first attempt you will be prompted to create an _acme-challenge CNAME record in your DNS pointing to the acme-dns service. So for instance if your subdomain was
apithe CNAME will be called _acme-challenge.api - you add this using your Hostinger DNS control panel. - Once you have created the CNAME record as prompted, return to your managed certificate in the app and click Request Certificate to resume the paused certificate order. If you setup your CNAME record properly you will now have a new certificate.
Once you have your certificate you need to use it with your service, that will depend on your programming language for the IoT board and what certificate file requirements it has.
Certify produces a PFX file by default but you can convert that to PEM format for most other service types by adding a Deploy to Generic Server task under the Tasks tab, then save the settings and run the task to generate the files (you will normally need the fullchain.pem file for your cert and the privkey.pem file for your cert private key).
Then copy the files to the IoT board file system or whatever you need to do to get a certificate working on that.
3 Likes
Specifically, Let's Encrypt doesn't issue certificates for IP addresses, only for DNS domain names. Other certificate authorities may issue (paid) certificates for (stable, public) IP addresses, like you can see at https://1.1.1.1/ and https://8.8.8.8/.
This is a very important point. Since we're talking about publicly trusted certificates here, the browser developers have created a large body of rules which are meant to protect the general public from domain name impersonation. Let's Encrypt (with the help of software developers like yourself) has been able to automate this process very well from the point of view of public web sites that are hosted at a hosting provider. It is not automated well from the point of view of other use cases, but the same rules still apply to protect the public—although the process may become very annoying.
It's worth repeating that these rules were not made up by Let's Encrypt; they were made up by a whole industry process, at the impetus of the web browser developers, and they exist mainly to protect the public as a whole. Let's Encrypt isn't allowed to ignore or skip over these rules; if it did, browsers would punish it by removing public trust from its certificates.
Posso repetir isso em português se fosse útil.
3 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.