I have no root rights on my site, and I have to use control panel to instal the certificate. But while my site’s NS are pointing to another server, the only possibility I have (and it was also suggested by my hosting support team) is to get certificate manually at local machine and then upload it in my control panel.
If it is right, how can I do it? If not - how can i solve my problem and install Let’s encrypt certificate?
If you are able to upload files to your site and have them appear in any name under that site, then one option is Certbot’s manual mode. In this mode Certbot will produce a file, and explain where the file needs to be placed on your website, the existence of this file on the site demonstrates to Let’s Encrypt that you really control the site.
This is not very automatic though, so it will require ongoing dedication to perform the same steps again every 2-3 months to replace the certificate before it expires. Some popular Control Panel software has upgrades available where it will automate Let’s Encrypt certificates for you, which would be much less work if it’s possible to take this path.
Thank you for help!
I did succeed to get certificate in manual mode. But now the problem is that I can not really get cert-files on my local machine. They are on some remote server and strongly resist downloading (though they have 777 rights mode). The manual says that “Rather than copying, please point your (web) server configuration directly to those files (or create symlinks)”, but what I need is the real file, which should be uploaded using Control Panel of my hosting. I have no access to my (web) server configuration.
That’s all very stupid I know, but i can’t solve the problem myself…
What do you mean by “strongly resist downloading”? How are you trying to download them and what kind of error or problem do you experience? Which manual told you not to copy them?
Did you create these certificates by running certbot --manual or something similar on the remote server?
When you ran Certbot, you either used sudo or you ran certbot-auto, which itself uses sudo. Thus, these files were created by root, not by your user account. This is intentional because on a multi-user system, only users with administrative privileges are supposed to be able to read these files, because they include a cryptographic private key which could be used to pretend to be the server!
You may have been confused about the files’ permissions because the apparent 777 permissions are a result of the use of symbolic links. Symbolic links on Unix always appear to have mode 777, but the effective permission that controls whether the file contents can be read is the permission of the target of the link, not of the link itself. If you run ls -l or stat on these links, you can see where they really point.