Connection aborted. OSError 107

Its a fresh installation only for certbot, still using nginx
I started having problems renewing on my old ubuntu 14.04 installations in the last few weeks
(~# curl -4 https://acme-v02.api.letsencrypt.org
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to acme-v02.api.letsencrypt.org:443)
So i made this fresh install for the sole purpose of creating and renewing the certs.

On the same disk(s) as before?

No, its a new VM ubuntu 18.04

But is it in the same hyper-visor host?
[using the same disk(s)]

Are they local or remotely mounted disks?

Yes same host, are you saying I should try to reboot the host? (that’s really a last case for me)

I wouldn’t got there just yet…
Can you check the drive subsystem?
Any alarms/failures/etc. related to disk access?
Can you inspect them visually?
[a lot of times you can see rows of green blinking lights and the one red/yellow/orange light crying for help!]

Please use Google and read some of the results.

One of your mount points doesn’t work, so it’s not a problem of a program. Instead, it’s a problem of your hardware. Unmounting in a running system may be more critical then rebooting the system.

In a perfect world, he would be using a hot-swappable drive subsystem.
And only one drive is going bad in a raid5 system and it’s just pull one out and put a new one in.
But you may be right, I may be crazy.
[Billy Joel in my head now]

1 Like

I am using hot-swappable but the world still aint perfect :wink:
I don’t have physical access to the server at the moment but I used “hpacucli” to check the condition of the 8 drives and the array, all reported “OK”.
Cant see anything relevant in logs.
If its a mount point a reboot of the VM should have resolved it.
I will play google for a little longer and if no joy I will reboot the server later.

1 Like

Best of luck :slight_smile:
You should run some sort of disk benchmark tool to prove its condition.
[perhaps a driver was recently updated and BAM!]

I tested all the drives today (removed 1 by 1 and created some large files and allowed the raid to rebuild, all without issue.)
Rebooted now and issue remains.
what a shame that i broke this record ->
root@serv-0:~# uptime
20:30:34 up 1196 days, 20:26,

Form my google searches I did not find anywhere that’s its hardware / mount point related, all i found is its problem in the python code.

Any ideas please?

And we start again… :slight_smile:

Force the renewal challenge location to a less used and 100% stable path…?

Not sure what you mean

The “default” location for the challenge file is /your/document_root/.well-known/acme-challenge/
This can be overridden to any location via an nginx location statement.

With something like this in your port 80 vhost config:

 location /.well-known/acme-challenge/ {
  root /some/stable/path/; #<<<change that to your specific location
  try_files $uri =404;
 }#location

are you sure it requires /acme-challenge/ in the path? i never used that before, in any case I tried now with and without still have same error.

My main nginx config now has
location /.well-known/acme-challenge/ {
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://192.168.10.15 ;
}
The server I am running certbot on now has
location /.well-known/acme-challenge/ {
alias /var/www/html/.well-known/ ;
}
i put a text file in /.well-known/acme-challenge/ and its reachable from the web, no issue

I tried few other location including home dir and /usr/share/nginx/html/certbot/ same issue.

IMHO It is 100% a issue with the renewal script or something in default config.
~# certbot certolny --webroot -w /var/www/html/ -d www.example.com -d example.com -d example1.com -d example3.com -d example4.com -d example5.com -d example6.com -d example7.com -d www.example8.com -d example8.com


2: Renew & replace the cert (limit ~5 per 7 days)


Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 2
Renewing an existing certificate

IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at:
1 Like

Not sure about the “alias inside location” vs “root inside location”…
[that is for another day]

My point was to set the location (via alias or root) to ANOTHER place; one more likely to be highly available and less in use (that could be: /tmp for all I know - I don’t know your system).

This VM has zero use, i set it up purely to generate / renew certs, its not an availability issue.

its a clean ubuntu 18.04 server install all default configs only packages i installed are those required to run cerbot

is there a way to manually renew non-interactively?
[certbot certonly --webroot -w /var/www/html/ -d www.example.com -d example.com]
i will just create a cron job to run this

That is the end-goal.
But it depends on the questions asked, or steps required, during the renewal process.
It should be “taught” enough to renew on its’ own.
Somethings like DNS TXT records, however, always have to be done manually (or handled through an API/plugin).