Configuration of two domains one with ssl one without

[Lexe]

Hello all,

I have a question of best practice with ssl configuration. Here is my case.

Let's say we have two domains house.com and little_house.com

The little_house.com will not have any web content, it exists just to get traffic for house.com, so I would like to redirect all traffic from little_house.com to the main domain house.com

Domain house.com should be available in http and https version.

For this scenario please tell me what is the best practice and if it makes sense what I did:

1. Create Virtual Host house.com.conf for domain house.com that will rewrite domain to ssl version as follows:

<VirtualHost *:80>
	    ServerAdmin admin@house.com
        ServerName house.com
        ServerAlias www.house.com

        DocumentRoot /var/www/html/house.com/public

        ErrorLog /var/www/html/house.com/logs/error.log
        CustomLog /var/www/html/house.com/logs/access.log combined

	RewriteEngine on
	RewriteCond %{SERVER_NAME} =www.house.com [OR]
	RewriteCond %{SERVER_NAME} =house.com
	RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

2. Create another Virtual Host house.com-le-ssl.conf for domain house.com with cert ssl as follows:

<VirtualHost *:443>
        ServerAdmin admin@house.com
        ServerName house.com
        ServerAlias www.house.com

        DocumentRoot /var/www/html/house.com/public

        ErrorLog /var/www/html/house.com/logs/error.log
        CustomLog /var/www/html/house.com/logs/access.log combined

	Include /etc/letsencrypt/options-ssl-apache.conf
	SSLCertificateFile /etc/letsencrypt/live/house.com/fullchain.pem
	SSLCertificateKeyFile /etc/letsencrypt/live/house.com/privkey.pem
</VirtualHost>

3. Create Virtual Host little_house.com.conf for domain little_house.com without any cert ssl. Just pure rewrite to ssl version of house.com. I mean https://house.com as follows:

<VirtualHost *:80>
        ServerAdmin admin@little_house.com
        ServerName little_house.com
        ServerAlias www.little_house.com

        ErrorLog /var/www/html/house.com/logs/error.log
        CustomLog /var/www/html/house.com/logs/access.log combined

	RewriteEngine on
	RewriteCond %{SERVER_NAME} =little_house.com [OR]
	RewriteCond %{SERVER_NAME} =www.little_house.com
	RewriteRule ^ https://house.com%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

Is it a good approach? In that solution I will "loose" traffic from ssl version of domain little_house.com

What is the best practice for my case?

Thank you for any suggestions and hints.

[rg305]

@Lexe

Is it a good approach?

The three parts are good [so far].
But you are missing the fourth part: Handling https://little_house.com/

@Lexe

What is the best practice for my case?

Handle all possible cases with the least amount of client inconvenience:
[usually something like]

1. http://example.com/ > redirect to https
2. https://example.com/ serve the site/content here
3. http://another.example.com/ > redirect to https
4. https://another.example.com/ > redirect to https://example.com/

Which means you will need to get a cert [or certs] to cover both names.
If the names are pointing to the same IP, you could combine them easily onto one cert.

[Lexe]

Thank you for your comment Rudy.

That was exactly my doubt if I should generate two certs or better is to combine house.com and little_house.com together.

Thank you for confirming that all normal people configure this way.
Happy Friday

[Lexe]

@rg305

Handle all possible cases with the least amount of client inconvenience:

Does your words "client inconvenience" mean as few virtual hosts as possible or something else?

If I "combine" many domains in one cert then I will need to generate new cert if I will need to take off one domain?

[rg305]

@Lexe

Does your words "client inconvenience" mean as few virtual hosts as possible or something else?

As few redirects/clicks for the client/visitor.

@Lexe

If I "combine" many domains in one cert then I will need to generate new cert if I will need to take off one domain?

All "changes" to a cert require creating a new cert - they can't be "modified/edited".

[Lexe]

@rg305

All "changes" to a cert require creating a new cert - they can't be "modified/edited".

What will happen if I will keep "combined" cert, and for one domain from the "combined bucket" will change DNS IP and try to generate a brand new cert? Can it be done like that? Will the combined domain with combined cert still work? Just wondering.

I apologies if something my questions are weird, but I am completely new in topic of ssl certifications.

[schoen]

@Lexe

What will happen if I will keep "combined" cert, and for one domain from the "combined bucket" will change DNS IP and try to generate a brand new cert? Can it be done like that? Will the combined domain with combined cert still work? Just wondering.

The certificate itself is valid on any server where it's installed with the matching private key, regardless of whether that's the same or different server where the certificate was obtained, and regardless of whether the certificate is used on one or more servers at the same time.

However, it could be difficult to get Let's Encrypt to issue a renewal certificate to replace the combined certificate in the future, if the domains are no longer pointing to the same server, since whatever server tried to make the request might not be able to satisfy the certificate authority's proof-of-control challenges anymore.

Challenge Types - Let's Encrypt

Since Certbot and other Let's Encrypt client applications normally request a certificate with the same domain name coverage as the old certificate had, the renewal attempts would fail if one or more of the covered domains can't be included in the new certificate.

[Lexe]

That's clear and nice explanation. It is more understandable for me now.

Thank you so much.

[Lexe]

@rg305

Handle all possible cases with the least amount of client inconvenience:
[usually something like]

1. http://example.com/ > redirect to https
2. https://example.com/ serve the site/content here
3. http://another.example.com/ > redirect to https
4. https://another.example.com/ > redirect to https://example.com/

You mentioned the least amount of client inconvenience (redirects/clicks). What about the configuration as below with one cert for example.com and another.example.com ?

1. http://example.com/ > redirect to https://example.com/
2. https://example.com/ serve the site/content here
3. http://another.example.com/ > redirect to https://example.com/
4. https://another.example.com/ > redirect to https://example.com/

[Lexe]

Ok. I see it saves one click, but I think it is worth.

[rg305]

@Lexe

I see it saves one click

That one saved redirection [which are automatic in all browsers] not one additional click saved.
And it is actually preferred NOT to switch from HTTP to HTTPS while also switching from domain1 to domain2.
[but that should be possible]

[Lexe]

@rg305

And it is actually preferred NOT to switch from HTTP to HTTPS while also switching from domain1 to domain2.

So, I assume more "natural" and elegant is your proposal. What's different between rewrite and click? I didn't get that difference

[rg305]

The difference is that the client does nothing.
The browser makes a request the web servers reply says "that's not here, look elsewhere" and the browser automatically goes and looks "elsewhere" for it.

[Lexe]

I think I do not have more questions. Seems to be more clear now for me.

Thank you so much for sharing the knowledge.

I have a few questions of Internationalised Domain Names (IDNs) and its ssl configuration, but it it out of this topic. I will describe what is my concern and open another one.

Thank you so much for your help and time. I appreciate it.