Hi folks,
I finally founded an acme client I can use with acme-dns, with a gui for the team.
Currently testing with community release, we plan to buy a licence if I can achieve ssh connections through bastion.
Here is my workflow for ~ 200hosts :
Add a host in certifytheweb, letsencrypt with dns challenge using acme-dns.
Task 1 : push the pfx (full cert + key) on remote in /etc/ssl/certs/
Task 2 : run a custom shell script which extract cert and key from pfx, move cert/key in correct location and archive the oldest.
Task 3 : restart service using systemctl remotely.
Everything is working fine : cert generation, renewal, deployement and restart directly for this host. But, for security purposes we use a wallix bastion to open ssh connections on our servers.
With this proxy I can use a simple user with few ssh permissions (only scp on upload for example).
On my computer when I want to connect to a server I use this connection chain :
remote host : IP.SSH.PROXY
username : root@hostname:myusername
Then, I authenticate myself on the proxy with username, proxy verify my credentials and permissions and it opens a root connection on remote.
Is there a way to deal with this setup ? Anyone already achieved to do it ?
By the way if it can’t works, I’ll drop ctw I think and I’ll use another linux client with acme-dns support, bye bye nice gui
Hi, thanks I’m not familiar with Bastion at all, but I’m sure it’s not an unsurmountable problem. Can you describe why this doesn’t work currently?
You can simplify the custom shell script step by using the certificate export or Generic Server deployment tasks (which understand ssh/sftp) to export pem etc instead of PFX.
Note that you can also work outside of certify if that’s easier, so setup all your certs to export to a local or network file system, then have something on the hosts that reach out and get their latest cert on a regular basis. There are also plans for Certify to have an API whereby you can curl etc with an API token to the certify server to get your latest cert copy, if that sounds useful. Still some work to do there to make that happen but it is still planned.
You also have the option of using a deployment task to push Certs to a secrets store (HashiCorp Vault etc) then pull them form the hosts, that feature already exists.
Regarding other clients, you should indeed use the tool that you find is best for the job and I wonder in this case if the hosts should be more responsible for their own certs?
Incidentally we are also working on linux/docker support for the server side of Certify, which opens up a new range of ways to use the service for centralised certificate renewal management. The service can now run on Linux but we’re working on filling out the authentication options and the UI is still windows-only for now (although it can connect to any service).
Hi and thanks for your reply.
Everything is working except ssh connection through the ssh proxy. But yesterday I moved forward and found a solution, or something close.
For those who are interested : here is my connection chain root@passwordPolicy@Target:SSH:TypeOfConnection:ProxyUsername@domain@ProxyIp
It’s clear from the beginning it’s not a ctw problem, I was looking for people using a ssh proxy and export over ssh.
Good news for the docker server. Does it means that the client side will still be on windows and it will connect to the server backend using api ? A good choice for licensing I guess, the more the client is installed, the more we’ll need licences ?
Anyway, good news ! Do you think about a web interface ? Does the server api will be documented and acessible from a custom client ?
Licensing hasn’t been worked out for the server backend version but one UI could connect to many servers. Really licensing is about paying for supported software more than it is about paying for the use of the software and it’s a balance to fund the development/support vs making it accessible to as many people as possible. Obviously for most businesses it costs more to have a meeting to discuss using our software than it does to actually buy the license.
Yes, as part of the central server product there would be an API for general application use and the API would be documented and be accessible from any programming/scripting environment.
… and yes a web interface is being considered but whatever approach we take has to be unified as we don’t have the resources to develop and maintain both a desktop and web UI with the full set of features.
Well, many good news incoming so
You are right, the license is very accessible, and yep, it’s more expensive to create a meeting with many people, expose the solution, talk about etc, than directly buy the license and try it out.
I think (but I’m maybe wrong), the web interface will create and federate many people. For the moment, your software is already very good, that give hope about your future developments
Re,
I gaved a try in the morning to connect through our ssh proxy but I don’t really understand how is working the part between credentials and target.
For example, from my linux laptop here is how I can connect to one of our server :
Pass-policy : registered variable on the bastion corresponding to the root password on target
srv-backups : the target I want to connect to
SSH : the group policy variable on the bastion
Connection-policy : the group authorization
ldapuser@ldapsrv : my corporate username@domain. This credential is used to authenticate my self on the bastion, then the bastion retrieves my authorizations and permissions.
ssh-bastion : the ip of our bastion.
Well, this chain allows me to connect on my target through the bastion this way :
From my laptop using openssh client, it’s quite easy to deal with this chain and it just works.
Using rencyssh and certiytheweb, I don’t really know how to do : what is the part for username, what part for target ?
Looking at the code the first problem is that we expect : to mean host:port, so it’s not going to work (yet) unless there is some other separator that can be used.
A workaround is to export the cert locally then run your own ssh/sftp command as a bat file to do the rest. This has the disadvantage that you probably need to store credentials somewhere but it has the advantage that you can use the same script with some variable substitution for different hosts etc.
Note that some external ssh commands have been known to hang, e.g. some older versions of openssl.
