1 out of 2 subdomains cannot be switched to https

Help
1

Hello to all,

I've come to see you because I've just changed my certificate. Indeed, I had a classic self-signed certificate with let's encrypt, but I have 2 sub-domains and after some research I found that I had to generate a wildcard certificate and not a lambda certificate.

I managed to generate via the API of ovh (because I am with them) the precious sesame, and I find myself with :

_ My main domain aseaction.fr which works correctly.

_ My subdomain www.aseaction.fr which also works with a certificate.

But I have a last sub-domain cooperations.aseaction.fr which doesn't want to go to https, and I don't understand why, here is the corresponding vhost file, I have regenerated a certificate especially for this domain with the command :

certbot certonly --dns-ovh --dns-ovh-credentials ovh.txt -d cooperations.aseaction.fr

The command works and the certificate is correctly generated, unfortunately, when I indicate the right path in the vhost and I restart apache I see that I am still not in https.

I have at one time succeeded (I do not even know how) to pass it in "semi secure" I mean that the domain was not automatically redirected in https but when manually we put the s the certificate was present. This is not even the case anymore.

I don't really understand, if my subdomain www.aseaction.fr works correctly it's because the certificate supports subdomains, so why nothing happens with cooperations.aseaction.fr ...

By activating certbot without any command it returns us this :

Which names would you like to activate HTTPS for?

1: aseaction.com
2: www.aseaction.fr

We can see that it does not detect cooperations.aseaction.fr which is also strange ...

My vhost file of cooperations.aseaction.fr

<IfModule mod_ssl.c>
<VirtualHost *:443>

#ServerAlias aseaction.cooperations.fr

ServerAdmin contact@aseaction.fr
ServerName cooperations.aseaction.fr
DocumentRoot /var/www/aseaction/

#ServerAlias aseaction.cooperations.fr

    <Directory /var/www/aseaction/>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    <IfModule mod_dir.c>
        DirectoryIndex index.php index.pl index.cgi index.html index.xhtml index.htm
    </IfModule>
RewriteEngine on
SSLCertificateFile /etc/letsencrypt/live/cooperations.aseaction.fr/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/cooperations.aseaction.fr/privkey.pem
RewriteCond %{SERVER_NAME} = cooperations.aseaction.fr
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

For the configuration I use a version of certbot in 1.24 as well as apache as web server and a debian 10 (version5.10)

Thank you in advance to all, and if you wish additional information I am at your disposal.

Sincerely,

1 Like
3

Do you have an actual virtualhost for that third FQDN?

Certbot lists domain names from those (the ServerName and ServerAlias directives).

It will get you a certificate for any FQDN pointing to your server, though. (Or any at all in your DNS zone, seeing that you use dns-01 validation)

1 Like
4

If I try going on httpS://cooperations.aseaction.fr/ I get a certificate warning about the wrong name.

But you are using dns-01 validation. You can solve all your problems by replacing all your certificates with a single wildcard one, that you get by running

certbot certonly --dns-ovh --dns-ovh-credentials ovh.txt -d aseaction.fr -d '*.aseaction.fr'

(NB: it's valid for any name.aseaction.fr, but not prename.name.aseaction.fr including www.name.aseaction.fr)

2 Likes
5

Thank you for your answer @9peppe

With the command you gave me I have this warning :

Error determining zone identifier for aseaction.fr: 403 Client Error: Forbidden for url: https://eu.api.ovh.com/1.0/domain/zone/. (Are your Application Key and Consumer Key values correct?)
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

It's weird because it's the same txt file used for the command I entered above, so the ovh.txt keys are apparently correct

I don't know what you mean by "real" vitualhost ? if the question is to know if the vhost is physically in the server the answer is yes, here is the result of an ls

ls /etc/apache2/sites-available/
000-default.conf aseaction.conf aseactionSsl.conf cooperations.conf cooperations_ssl.conf default-ssl.conf trash www.aseaction-le-ssl.conf www.aseaction.conf

EDIT: The trash folder is simply a folder that I used to exclude files without deleting them in order to test different hypotheses as to why this problem occurs

1 Like
6

What's this supposed to look like? Probably not this. Is there a wild dot roaming around in your command line?

Oh, wait. Your apex domain is .com, not .fr. And aseaction.com is NXDOMAIN, it hasn't been registered.

Do you want a certificate for aseaction.fr? Where are its DNS hosted? Did you delegate NS to OVH for your subdomains only? -- no, you didn't.

You should probably search the OVH API reference to understand what this error means.

And sites-enabled?

What matters are those two directives. ServerName and ServerAlias.

1 Like
7

I use an automatic translator, so please forgive me if I don't understand all the words literally, even if on the whole it should be fine.

Oh, wait. Your apex domain is .compas .fr.

What do you mean by "my apex domain"?

I want a certificate for all 3 domain names. And for now aseaction.fr has one that works fine and the same for www.aseaction.fr it's only cooperations.aseaction that is the problem.

Indeed, you are right, I had forgotten to add the NS in my zone, I am doing it right now, I am waiting for the propagation and I will try again.

Blockquote

8

What directory is that file in and what directory were you in when you ran that command?

You should probably use an absolute position, like

  • --dns-ovh-credentials ~/ovh.txt
  • --dns-ovh-credentials /root/secrets/ovh.txt
1 Like
9

We have french speakers if you want them.

I'm learning the language and I can only read simple phrases.

The domain you actually bought, as opposed to the subdomains.

1 Like
10

For the moment we manage to understand each other, and then it can be a mutual enrichment, because I too am learning English, but I am in the same case as you, I can only read simple sentences :slight_smile:

The file is in the root, and it's the place where I am now and where the command was executed (with always the same error message)

The actual domain purchased is aseaction.fr

1 Like
11

Here they suggest expired credentials. It doesn't sound that right to me but it's worth checking it out:

1 Like
12

I have just regenerated the token but I have the same message

13

The DNS plugin did work before, right?

I'd check the OVH documentation.

1 Like
14

The command works but only when using this command certbot certonly --dns-ovh --dns-ovh-credentials ovh.txt -d cooperations.aseaction.fr

This one on the other hand does not work:

certbot certonly --dns-ovh --dns-ovh-credentials ovh.txt -d aseaction.fr -d '*.aseaction.fr'

I used the command that works by replacing the domain with *.aseaction.fr and this time the error message appears again, so it seems that it is somehow related to the entry of *.aseaction.fr

15

This doesn't make any sense. I don't understand it.

You did use single quotes ', not double ones ", right?

1 Like
16

Please use the staging environment for testing. Currently, you already have issued manycertificates the last few days. Besides the fact that issuing duplicate certificates unnecessarily is only adding load to the Let's Encrypt infrastructure unnecessarily, you can also hit rate limits.

See your history here: https://crt.sh/?q=aseaction.fr&deduplicate=Y

Further more, I'm not familiar with the OHV credential system, but I think the problem is probably related to credentials.

4 Likes
17

@9peppe Yes, I used the right quotation marks.

@Osiris And yes indeed I generated many certificates because I tested many things, but you are right I guess it was not useful and I should not have done it.

Concerning the credentials I don't think that's where it comes from, because to generate the key values you have to identify yourself otherwise the values are not generated by the API. So the ids are good, since the API correctly returned the values of the different keys used

What do you call the test environment? Are you referring to a localhost site corresponding to the NS files?

18

Add --dry-run to your certbot commands.

It looks like it is.

@arawaks did you set the right access rights for your API key?

2 Likes
19

The name you are trying to make HTTPS, is listed in an HTTPS vhost:

This can be problematic:

2 Likes
20

See the following documentation page:

The option suggested by @9peppe will make Certbot use this staging environment.

3 Likes
21

@peep

For the API rights I gave him a little bit of everything just to be sure. The actual configuration should be something like this.

api ovh

@rg305 yes, unless I'm mistaken the way to proceed that I could see in various articles were this one, currently I have in /etc/apache/site-available/ 2 files per domain, 1 containing a vhost on port 80 and another one separately listening on port 443.
Comme ceci :

vhost
vhost692Ă—925 28.6 KB

Why is that? Nginx would be preferable in your opinion?