Skip to content
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

Ability to manage SSL Certificates #88

Open
Russell-IO opened this issue Dec 27, 2022 · 4 comments
Open

Ability to manage SSL Certificates #88

Russell-IO opened this issue Dec 27, 2022 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@Russell-IO
Copy link

It would be very cool to help add support for let's encrypt by combining with the acme provider, things needed for this:

Lifecycle of certificate
Assign to services, api, www, ikev2

@Russell-IO Russell-IO added the enhancement New feature or request label Dec 27, 2022
@OJFord
Copy link
Contributor

OJFord commented Feb 28, 2024

It's now built-in (ROS v7) for the 'www-ssl' service: https://help.mikrotik.com/docs/display/ROS/Certificates#Certificates-Let'sEncryptcertificates

It'd be good to support that so that if enabled manually in order to give this provider access, that configuration (though necessarily already done manually) could at least be recorded, something like:

resource "routeros_ip_cloud" "router" {
    ddns_enabled = true
}

resource "routeros_certificate" "router" {
    enable_ssl_certificate = true
}

// firewall rules

I might be able to look into it some time in the next few days.


Just editing to add I had the briefest of looks already - seems the way it works is you POST /rest/certificate/enable-ssl-certificate (optionally with the DNS name else it uses DDNS from /ip/cloud) and then it gets created in certificates along with any others manually created. So there isn't a separate LE resource even conceptually really, for read/refresh we'd need to filter the full list for it, but it either exists or it doesn't, so then we could populate Boolean enabled on that basis.

Given that though it probably does make more sense for it to be its own tf resource, so rather than above it would be like:

resource "routeros_certificate_lets_encrypt" "router" {
    enabled = true
}

perhaps.

Since a certificate resource we might want multiple of, but it doesn't make sense to enable the LE one or not on each one, it's a separate one-shot action.

I'll hopefully get around to a PR Friday or Sunday.

@OJFord
Copy link
Contributor

OJFord commented Mar 26, 2024

Sorry I didn't get to this because I realised I can't use it (or hence test it) personally since I'm behind CGNAT, and the built-in support doesn't allow for DNS challenge.

I think the acme_certificate integration you suggest would be good, but really that belongs as a separate Terraform module, using both this & the acme provider.

Support for the built-in Let's Encrypt cert would be good too (in this provider) but that's tied to the www-ssl service and not quite what you were asking for.

@vaerh
Copy link
Collaborator

vaerh commented Mar 26, 2024

I have not taken on this task precisely because I have no way to test or debug the process of obtaining a LE certificate. I don't have a solution yet.

@OJFord
Copy link
Contributor

OJFord commented Mar 26, 2024

I'm intending to play around with the tailscale container, I suppose once I have that running it would make it feasible for me to test it (and also obviate any point of it really) but I'm a way off that yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants