So I went to the router, to the WAN section, then went to the "Virtal Server/Port Forwarding" section, and then in the "Port Forwarding List" section, I made the settings that I showed in the screenshot.
That looks good, so if http still not working you need to contact your ISP if you still want to use HTTP domain validation to get your certs. I would suggest switching back to manual DNS for now.
What do you mean by "manual DNS"?
But still, these two ports 80 and 443 should be visible from the outside, but only 443 is visible. 
In your very first post you used:
This is using a DNS challenge to prove you control your domain (instead of an HTTP challenge), manually updating an _acme-challenge TXT record in DNS. That's what I mean by validating your domain using "manual DNS". The only thing wrong with this original approach was probably not waiting long enough after editing DNS for the changes to sync in DNS (across your domains nameservers).
Okay, I'll try to do it this way. I hope this helps, because the site has been down for 4 days due to a certificate issue.
I tried to enter it through DNS, and it gave me the following message:
sudo certbot certonly --manual --agree-tos --email MY_EMAIL --server https://acme-v02.api.letsencrypt.org/directory --preferred-challenge=
dns -d lkmpikt.org -d *.lkmpikt.org
Another instance of Certbot is already running.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /tmp/certbot-log-6m0tob5g/log or re-run Certbot with -v for more details.
Here are the contents of the log:
sudo cat /tmp/certbot-log-6m0tob5g/log
2025-08-06 12:55:10,212:DEBUG:urllib3.connectionpool:http://localhost:None "GET /v2/connections?snap=certbot&interface=content HTTP/1.1" 200 97
2025-08-06 12:55:10,456:DEBUG:certbot._internal.main:certbot version: 4.2.0
2025-08-06 12:55:10,456:DEBUG:certbot._internal.main:Location of certbot entry point: /snap/certbot/4892/bin/certbot
2025-08-06 12:55:10,456:DEBUG:certbot._internal.main:Arguments: ['--manual', '--agree-tos', '--email', 'k_vadim@list.ru', '--server', 'https://acme-v02.api.letsencrypt.org/directory', '--preferred-challenge=dns', '-d', 'lkmpikt.org', '-d', '*.lkmpikt.org', '--preconfigured-renewal']
2025-08-06 12:55:10,456:DEBUG:certbot._internal.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2025-08-06 12:55:10,468:DEBUG:certbot._internal.lock:A lock on /var/log/letsencrypt/.certbot.lock is held by another process.
2025-08-06 12:55:10,468:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
File "/snap/certbot/4892/lib/python3.12/site-packages/certbot/_internal/lock.py", line 126, in _try_lock
fcntl.lockf(fd, fcntl.LOCK_EX | fcntl.LOCK_NB)
BlockingIOError: [Errno 11] Resource temporarily unavailable
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/snap/certbot/4892/bin/certbot", line 8, in <module>
sys.exit(main())
^^^^^^
File "/snap/certbot/4892/lib/python3.12/site-packages/certbot/main.py", line 19, in main
return internal_main.main(cli_args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/snap/certbot/4892/lib/python3.12/site-packages/certbot/_internal/main.py", line 1863, in main
log.post_arg_parse_setup(config)
File "/snap/certbot/4892/lib/python3.12/site-packages/certbot/_internal/log.py", line 110, in post_arg_parse_setup
file_handler, file_path = setup_log_file_handler(
^^^^^^^^^^^^^^^^^^^^^^^
File "/snap/certbot/4892/lib/python3.12/site-packages/certbot/_internal/log.py", line 164, in setup_log_file_handler
util.set_up_core_dir(config.logs_dir, 0o700, config.strict_permissions)
File "/snap/certbot/4892/lib/python3.12/site-packages/certbot/util.py", line 267, in set_up_core_dir
lock_dir_until_exit(directory)
File "/snap/certbot/4892/lib/python3.12/site-packages/certbot/util.py", line 241, in lock_dir_until_exit
_LOCKS[dir_path] = lock.lock_dir(dir_path)
^^^^^^^^^^^^^^^^^^^^^^^
File "/snap/certbot/4892/lib/python3.12/site-packages/certbot/_internal/lock.py", line 259, in lock_dir
return LockFile(os.path.join(dir_path, '.certbot.lock'))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/snap/certbot/4892/lib/python3.12/site-packages/certbot/_internal/lock.py", line 45, in __init__
self.acquire()
File "/snap/certbot/4892/lib/python3.12/site-packages/certbot/_internal/lock.py", line 60, in acquire
self._lock_mechanism.acquire()
File "/snap/certbot/4892/lib/python3.12/site-packages/certbot/_internal/lock.py", line 112, in acquire
self._try_lock(fd)
File "/snap/certbot/4892/lib/python3.12/site-packages/certbot/_internal/lock.py", line 130, in _try_lock
raise errors.LockError('Another instance of Certbot is already running.')
certbot.errors.LockError: Another instance of Certbot is already running.
2025-08-06 12:55:10,468:ERROR:certbot._internal.log:Another instance of Certbot is already running.
Your log says:
Maybe try restarting, or at least kill any running certbot processes, you may need to delete the lock file if the issue persists.
I restarted my PC. The command started. I tried it through DNS, made the entries, and now I have to wait about 15 minutes for the DNS data to update. If this doesn't work, I don't know what to do...
Can you give an example of one of the DNS entries you made
On the website of the domain name registrar, I selected the TXT field and added the name "_acme-challenge" and its random value. I did this twice, as indicated by certbot. Now I need to wait for the DNS data to update. Once updated, I will press Enter to complete the certbot process.
So, it seems that the certificate was issued through DNS, but now the question is, the site still doesn't open on hhtps, so what should I do to specify the files that certbot wrote in the settings?
Did you reload your nginx server? It needs that to see the new cert
No, I didn't know it needed to be restarted, and certbot didn't mention it.
Is it normal that it used to say "Common Name (CN) E11" if I remember correctly, but now it says "Common Name (CN) E6"?
A reload is all that is needed although restart works too. No, Certbot does not say anything about this when using manual mode.
We should also check which cert your nginx uses. What does this show
sudo certbot certificates
I restarted the service and the site started working, and now it displays that the certificate is valid.
It used to say R11 as you were using an RSA cert. You now are using an ECDSA cert so E6 is normal.
Do you need an RSA cert? Certbot has long used ECDSA as the default but we can request RSA
Good.
Your problem with HTTP port 80 might affect visitors to your site. If they try HTTP the connect will fail and your server won't have the chance to redirect them to HTTPS
One good thing is some modern browsers automatically try HTTPS and will ignore that HTTP is failing. Still, you should continue to try to resolve that problem
To be honest, I don't quite understand the difference. If it's not too much trouble, could you explain it to me?
Thanks for the information. I'll contact my provider then.
Google, chatGPT or similar could explain it better 
ECDSA has been Certbot's default for some time as the EFF felt that was the best. In some cases if you need to support visitors with very old devices they may require RSA. Run an SSL Labs report it probably shows a report of that. SSL Server Test (Powered by Qualys SSL Labs)