How to add wildcard to my existing letsencrypt certificate?

Hello,
I allready got a certificate i made like this:
certbot certonly --standalone --preferred-challenges http -d domain.com -d www.domain.com --email contact@domain.com
Now i would need to add wildcards to this certificate, is it possible without breaking anything ?
If so, how ?
Thank you

1 Like

Hi @Paradoks-Studio

please explain exact what you want to add.

You need to read about the differences in authentication for wildcards.
Which, presently, can only be done via DNS authentication.
So, "--preferred-challenges http" will not work.

Start here:

1 Like

@JuergenAuer
In fact i would like to be able to use subdomains like this:
My main site hosted on VPS1:

  • www.domain.com
    And my secondary site hosted on VPS2 but with the same cert:
  • VPS2.domain.com
    I am making a browser videogame with https, and i need to be able to sent players to differents servers but with the same cert.
1 Like

Are you looking for more than one different name or just two different names? Like, are you going to dynamically generate a large number of different names, or are you just planning to use the two names www.domain.com and vps2.domain.com?

In the second case, you wouldn't need a wildcard certificate at all.

1 Like

Also, could we ask why? Most users—and Javascript code as well as browser security policies—won't be able to distinguish at all between cases where different parts of your site are loaded from origins with the same cert or origins with different certs, as long as the certs are all valid for the names under which the respective origins are being accessed by the browser.

1 Like

@schoen
I would like to be able to add servers, VPS1.domain.com, VPS2.domain.com, etc...

I am not comfortable at all with certs and https stufs so could you explain me what you mean by:

won't be able to distinguish at all between cases where different parts of your site are loaded from origins with the same cert or origins with different certs, as long as the certs are all valid for the names under which the respective origins are being accessed by the browser

So far my game was running fine on simple http, it was running like this:
VPS1 is masterServer - this is the server with the cert on.
VPS2 is remoteSpawner - this server has no domain it has only an ip adress, this VPS must be revocable any time.
the spawner is the executable that actually generate the game rooms where players connect.
so:
1 - A player request a game to the masterServer VPS1
2 - The masterServer check if a remoteSpawner is available ( there can be many) if there is a remoteSpawner available, it sends its IP to the masterServer wich send it to the player to connect.
Everything was running well this way until https.
Now it bugs because:
1 - Now the client need to get a domain to connect to, not an ip anymore.
2 - The domain should be the same as the one with the cert.

So i thought i could do something like:
VPS1 registers a wildcard cert like: www.domain.com, VPS1.domain.com, VPS2.domain.com etc..
I would attribute the subdomains to the remoteSpawners, so when they send their adresses they send adresses that are in the cert, so it should work.
But maybe i am wrong and i don't even know how to make all this work.
What do you think ?

Is the number of these remote Spawners constant?

vps1.domain.com - vps15.domain.com

And are there max. 50 of these remote Spawners (or only a slowing increase)?

Is a server like vps15.domain.com able to run a Letsencrypt client (certbot) and to connect Letsencrypt?

If yes, one certificate per server with one domain name via http validation would work.

@JuergenAuer

Is the number of these remote Spawners constant?

No, I need to be able to adapt to the demand.

And are there max. 50 of these remote Spawners

There will probably be less than 10.

Is a server like vps15.domain.com able to run a Letsencrypt client (certbot) and to connect Letsencrypt?

I read that certbot could only run on registered domains, the remoteSpawners are on server only, i didnt registered any domain for them.

First is correct. But then your setup is unclear.

Are there public visible A-records

vps15.domain.com -> your-ip-15

Connects a browser vps15.domain.com?

Or connects a browser only domain.com or www.domain.com, so it's only something between domain.com and vps15.domain.com?

If a browser doesn't connect vps15.domain.com, you don't need a public trusted certificate with vps15.domain.com or a wildcard.

@JuergenAuer

Connects a browser vps15.domain.com ?

No browser will connect to vps15.domain.com as html pages, but browser will connect to it as the server that host the game they connect to. So:

1 - player connects to www.domain.com wich is the masterServer(VPS1)
2 - player request adress from masterServer(VPS1) where to connect.
3 - masterServer send to player the remoteServer(VPS2) adress : ex vps2.domain.com
4 - players webGL game redirects the it to VPS2 - but the adress bar keep the www.domain.com in it.
5 - when the game ends, the connection to VPS2 is ended.

Sorry if it is confusing.
btw, everything works when i am only in http.

It's not relevant if there is

  • a html page
  • a xml service
  • a webGL

So the browser uses vpn15.domain.com to connect. So a public visible A-record vpn15.domain.com -> one of your ip addresses is required.

So you can create a certificate with that domain name via http validation -> no wildcard required, that's always easier.

Use the same command (--standalone) from these machines with only one domain name.

@JuergenAuer
It works, and it was way simplier than i thought, thank you.
what i did:
1 - added a subdomain on my registrar like [A] vps2.domain.com that pointed to vps2 ip.
2 - created a cert on VPS2 for vps2.domain.com
And that's it.
BTW: i realized that it don't answer to the question of the title.

1 Like

Yep, only these two steps are required, that's all.

A wildcard requires dns validation, makes things more complicated. And if your dns provider doesn't support an API, you may use --manual, that's painful.

So simple certificates with http validation normally the easiest solution.

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.