I hope you’ve found a solution that works well for you.
To clarify some points from earlier, since you suggested that you were pretty curious and pretty unfamiliar with a lot of this stuff:
A traditional way of interacting with a computer is via a command line. In this case the interaction is textual, not graphical, and involves typing specific commands at a command prompt (essentially, the computer repeatedly asks “What do you want me to do now?” and you type text that instructs it what to do, and the computer then displays other text showing what happened).
Many different computer systems have supported this paradigm for interaction. The most famous that are still in use are Windows (via the CMD interpreter or the newer PowerShell) and Unix (including Linux and macOS). One controversial thing about command lines is that they usually require explicit study in order to be useful, because you have to learn what commands to use for what task (which is different between Windows and Unix, and slightly different even between different varieties of Unix systems), you have to spell everything exactly right, and there’s a virtually unlimited amount of detail.
I have actually literally written a book about the benefits and challenges of command line interaction with computers. Today it’s mainly associated with computer experts, but I consider it a valuable tradition and skill and encourage more people to become familiar with it. But again, it requires deliberate study and practice, and among other things the computer doesn’t usually directly suggest what you might do (instead, you have to, to some extent, know the commands to type to achieve the result that you wanted).
The program that you use to interact with a computer via a command line is called a terminal emulator, or “terminal” for short. This is a program that shows a window of text and lets you type text to the computer and then see what the computer shows you in return. Many system administrators and computer programmers use this kind of textual environment as one of their primary ways of interacting with computers all day long. There is also a standard tool to connect to a command line on a remote computer over the Internet, usually as a means of remotely administering a Unix server. This forms an alternative to, for example, a web-based control panel as an interface for administering the computer and for many other purposes. It is MUCH, MUCH, MUCH more powerful than a control panel for this purpose and also much less intuitive.
The tool that we use to interact with a remote computer via a command-line interface is called ssh (also sometimes written SSH), for “secure shell”. Some terminal emulators, like PuTTY for Windows, have their own built-in ssh support. In other software environments, you might run an ssh command on your own computer’s command line and tell it to connect to a remote computer, and then, after connecting, you start typing commands to the remote computer instead of your own computer, and seeing the replies from the remote computer instead of your own computer. This is called “sshing into” the other computer, or “accessing it via ssh”, or sometimes just “logging into it”.
Almost all documentation that you may find about doing something with a command line on a server on the Internet assumes that you already logged into that computer via ssh, and are interacting with a command prompt provided by the server.
A considerable amount of software related to science and engineering, and also to computer system administration and network, is designed to work in this kind of textual environment, and is referred to as “command-line software”, or software that you use from the command line. Most of the Let’s Encryption client applications (which are programs meant to help you obtain a certificate from the Let’s Encrypt certificate authority) are of this kind, and are mainly intended for at least moderately experienced system administrators who are comfortable interacting with their servers through a command line to some extent.
Most of these client applications are also ideally meant to be installed on your server, not on your own personal computer, which is an occasional source of confusion (and I’m concerned that when you installed git, you might have been on a path to trying to make Certbot run directly on your own computer, instead of on your web server; but unfortunately running it on your computer is rarely the most straightforward way to use it).
The Let’s Encrypt service provides a public API (software interface) called ACME, which is meant to be used by a very wide range of software to request certificates. This can create confusion because there is not just one program or one way of getting certificates. For example, the gethttpsforfree.com site that you mentioned is yet another tool that does this, which is not run directly by Let’s Encrypt itself, and which serves as an alternative to a command-line Let’s Encrypt client such as Certbot. They are not the same tool or the same method for getting your certificate, but are actually competitors (of a sort).
The web-based Let’s Encrypt clients such as gethttpsforfree.com and zerossl.com are very useful options for people on shared hosting and those who are not very familiar with using a command line to administer their computers, because they let you do (almost) everything inside your web browser and then download the certificate at the end, and then you can potentially upload the certificate to your hosting provider via a web interface such as a control panel. However, a disadvantage is that they can’t automatically renew your certificate, so you have to keep repeating this process over and over. Many of the command-line-based options do provide some kind of convenient way to tell the web server to automate the renewal process, so that you won’t have to interact with this process manually very often in the future.
One thing that I think you’ve seen is that hosting providers have an enormous amount of control over your experience and capabilities in this regard. They can choose to absolutely forbid you to use third-party certificates at all (as we’ve seen with a few providers who apparently want to make sure customers pay extra for a certificate), and there’s approximately no way to get around this restriction. They can give you access to a command line via ssh on your web server, or not, or if they do so they can control how much ability you have to administer or reconfigure the server, or not. In that way, the command line is not a surefire way to get around restrictions from a hosting provider because the hosting provider can also ultimately control what you can or can’t do via the command line on its servers, just as the provider can control what you can or can’t do via a control panel.
git is a tool (originally created only in a command-line version) used for coordinating and managing software development among people who might not be in the same physical location. It keeps track of different versions of the software and the changes that people make, and lets people work together to reconcile potentially contradictory changes that they make to the software’s code. (In fact, it can be used to keep track of the history and versions of any set of documents that change over time and that one or more people work on together.) We use git to coordinate the development of Certbot, and it’s used to help create a very wide range of software. It is rarely a very convenient way to install software on your computer, and we at the Certbot project don’t endorse directly using git to install Certbot, even though some tutorials might suggest that method. This does not mean that you shouldn’t use git (it’s a great tool if you learn how it works!), but that it’s not really the best way to install Certbot or other Let’s Encrypt clients, in our opinion.
From what you’ve said, I doubt that Certbot will work well in your hosting environment and apparently you might not even be allowed to use third-party certs (such as Let’s Encrypt certs) at all. So that’s too bad, but maybe you’ll be in a situation in the future where you can!
There are also lots of great tutorials and guides online if you want to learn more about the command line! (Sometimes it’s a little bit unclear what “the command line” refers to in a particular case because it can encompass a particular shell, or command interpreter, as well as a particular set of accompanying tools that you use from the command line. Different people have different intuitions about what they would say is “part of” that command line environment or understand it. For example, git is traditionally used from a command line, yet different sources might disagree on whether learning to use it is included or not included in “learning to use the command line”.)
I’ve been using Unix command lines since 1993, still use them every day, and always feel that I have lots more to learn about them.