Could you please try this?
sudo certbot certonly --cert-name oceanwars.fr --webroot -w /var/www/html -d oceanwars.fr -d www.oceanwars.fr --expand --deploy-hook "apachectl -k graceful"
If that doesn't work:
sudo mv /etc/letsencrypt/renewal/oceanwars.fr.conf /etc/letsencrypt/renewal/oceanwars.fr.conf.bak
and try again:
sudo certbot certonly --cert-name oceanwars.fr --webroot -w /var/www/html -d oceanwars.fr -d www.oceanwars.fr --expand --deploy-hook "apachectl -k graceful"
It's not an issue with the local certbot as far as I know. I think it has to do with cached validations on the Let's Encrypt servers for some reason.
Thank you for your answer, I did all the commands:
Here is the full output:
root@712:~# sudo certbot certonly --cert-name oceanwars.fr --webroot -w /var/www/html -d oceanwars.fr -d www.oceanwars.fr --expand --deploy-hook "apachectl -k graceful"
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
You are updating certificate oceanwars.fr to include new domain(s):
+ www.oceanwars.fr
You are also removing previously included domain(s):
(None)
Did you intend to make this change?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(U)pdate cert/(C)ancel: U
Renewing an existing certificate
Performing the following challenges:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
root@712:~# sudo mv /etc/letsencrypt/renewal/oceanwars.fr.conf /etc/letsencrypt/renewal/oceanwars.fr.conf.bak
root@712:~# sudo certbot certonly --cert-name oceanwars.fr --webroot -w /var/www/html -d oceanwars.fr -d www.oceanwars.fr --expand --deploy-hook "apachectl -k graceful"
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
root@712:~#@Lockface77 Isn't the snap method of installing certbot an option for you? That way you'll have the most recent version of certbot available.
An alternative possible workaround would be to register a new account. I assume cached authorizations are connected to a specific account and using a new account would mean new authorizations.
No sorry, I can't install snap in my vps unfortunately.
I have recently contacted my hoster if you want to see what's happening:
root@712:~# sudo apt install snapd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
snapd
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 5374 kB of archives.
After this operation, 30.1 MB of additional disk space will be used.
Get:1 http://security.debian.org stretch/updates/main amd64 snapd amd64 2.21-2+deb9u1 [5374 kB]
Fetched 5374 kB in 0s (14.0 MB/s)
Selecting previously unselected package snapd.
(Reading database ... 26070 files and directories currently installed.)
Preparing to unpack .../snapd_2.21-2+deb9u1_amd64.deb ...
Unpacking snapd (2.21-2+deb9u1) ...
Setting up snapd (2.21-2+deb9u1) ...
Processing triggers for man-db (2.7.6.1-2) ...
root@712:~# sudo snap install core
error: cannot perform the following tasks:
- Mount snap "core" (10583) ([start snap-core-10583.mount] failed with exit status 1: Job for snap-core-10583.mount failed.
See "systemctl status snap-core-10583.mount" and "journalctl -xe" for details.
)
Unfortunately, I rode on the internet that in some hosters, they are too unable to install snapd on VPS.
I'm fairly certain that I've seen this issue numerous times with 0.28.0.
Unfortunate. Ah well, I'm not a fan of snapd myself..
Anyway, you could try to use a new account. Unfortunately, the certbot register feature REFUSES to work because you already have an account registered.. Which is a little bit strange, because my own staging setup has multiple accounts..
Anyway, you could try to move the directory in /etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory to a safe backup place. It has to be moved because if you only rename it, certbot will recognise the renamed directory. Once you've moved the existing account directory to a safe backup location, please try to run certbot again with the same options you've used earlier. It should ask you for your email address for notifications and it should ask you if you would like to register with EFF for some spam or something.
Depends what you call "issue". Versions of certbot >0.28.0 just had a way to de-activate the erroneous authorizations or something like that. You could say the issue is with certbot for not recognising that or the issue is with Boulder for not accepting new authorizations with a different challenge type.
I'm positive that a failed authorization isn't reused, so why would a new authorization have anything to do with a failed authorization? Maybe I'm misunderstanding what you're saying.
There are succesful authorizations with the dns-01 plugin. That's not compatible with the current attempt to use the apache plugin.
Thinking more about this, it might be a certbot issue after all.. But the workaround stays the same: with a new account there are no authorizations to speak of, so the command with the apache plugin should work.
That makes much more sense. I didn't equate "erroneous" to "cached successful".
I concur. That's a very wise workaround.
The command that you are talking about is this?
sudo certbot register --email EMAIL
Well.. "erroneous" for this specific case 
Just by moving the folder as said in here?
And then run the command
sudo certbot certonly --cert-name oceanwars.fr --webroot -w /var/www/html -d oceanwars.fr -d www.oceanwars.fr --expand --deploy-hook "apachectl -k graceful"
?
No. That won't help. You need to create a new account first.
Yes, you should run that command after you've moved your current account to a safe backup location, just to be sure.
I'm pretty sure certbot will just ask a few questions to register a new one Just like it would always do when you run it for the first time.
Normally as said by @Osiris it should ask me to create a new account during the command right?
I'm preeeeeeeetty sure it does. 99 % sure.. 
I was referring to the command to acquire a cert. @Lockface77 doesn't want to use webroot if not necessary.
I'm also pretty sure you can just run any command you want without a current account. Certbot probably will ask you for an e-mail, the current policy stuff and if you would like to get spammed by the EFF.. If you run certbot without any commands or run certbot run --whatever, I'm pretty much conviced it'll create an account no matter what.
Well, the webroot method is a pretty solid method of authentication. Robust against Apache configuration whoopsies. I'm not opposed to it.