Need to create cert for DN pointing to another DN

I have 2 domain names, both point to the same IP address. I can create a LetsEncrypt cert for the first DN, but I need to have a cert for the 2nd DN so that it doesn't get the 'Potential Security Risk' message. Is there any way to get a cert for the 2nd DN or possible have the 2nd DN default to the 1st DN's good cert? Or maybe there is some way to setup a Linux server to recognize itself having 2 DNs?

Note: I am not talking about a sub-domain here.
I tried -d myfirst.xyz -d www.myfirst.xyz -d mail.myfirst.xyz -d mysecond.xyz -d www.mysecond.xyz -d mail.mysecond.xyz

Thanks

It really doesn't matter for purposes of Let's Encrypt. What happened when you ran the command you gave?

3 Likes

Thanks for replying. Here is everything.

Note: I am using nginx_acme to create and update. It works with -d myfirst.xyz -d www.myfirst.xyz -d mail.myfirst.xyz alone.

sudo /root/nginx_acme -d myfirst.xyz -d www.myfirst.xyz -d mail.myfirst.xyz -d mysecond.net -d www.mysecond.net -d mail.mysecond.net

2021-09-07 08:51:10,311 - INFO - trying to create account key /etc/ssl/private/letsencrypt-account.key
2021-09-07 08:51:10,806 - INFO - trying to register acmev2 account
2021-09-07 08:51:12,062 - INFO - already registered
2021-09-07 08:51:12,063 - INFO - trying to create domain key
2021-09-07 08:51:12,063 - INFO - acmev2 http challenge
2021-09-07 08:51:12,064 - INFO - preparing new order
2021-09-07 08:51:13,957 - INFO - order created
2021-09-07 08:51:14,606 - INFO - verifying domain mysecond.net
2021-09-07 08:51:14,610 - INFO - adding nginx virtual host and completing challenge
2021-09-07 08:51:14,611 - INFO - created challenge file into /tmp/tmpzh36ulcr
2021-09-07 08:51:14,612 - INFO - writing virtual host into /etc/nginx/sites-enabled/0-letsencrypt.conf
2021-09-07 08:51:14,622 - INFO - killing nginx process 447 with HUP
2021-09-07 08:51:14,623 - INFO - writing challenge file into /etc/nginx/sites-enabled/0-letsencrypt.conf
2021-09-07 08:51:14,624 - INFO - asking acme server to verify challenge
2021-09-07 08:51:15,876 - INFO - waiting for mysecond.net challenge verification
2021-09-07 08:51:27,479 - ERROR - mysecond.net challenge did not pass: {'identifier': {'value': 'mysecond.net', 'type': 'dns'}, 'expires': '2021-09-14T13:51:13Z', 'status': 'invalid', 'challenges': [{'validated': '2021-09-07T13:51:15Z', 'error': {'detail': 'During secondary validation: Fetching http://mysecond.net/.well-known/acme-challenge/1ATF1lpS8BntayRI-T6PMgBWJDA_k91gJXUWLKjxAxw: Timeout during connect (likely firewall problem)', 'status': 400, 'type': 'urn:ietf:params:acme:error:connection'}, 'token': '1ATF1lpS8BntayRI-T6PMgBWJDA_k91gJXUWLKjxAxw', 'type': 'http-01', 'validationRecord': [{'port': '80', 'hostname': 'mysecond.net', 'addressesResolved': ['185.158.249.133'], 'addressUsed': '185.158.249.133', 'url': 'http://mysecond.net/.well-known/acme-challenge/1ATF1lpS8BntayRI-T6PMgBWJDA_k91gJXUWLKjxAxw'}], 'status': 'invalid', 'url': 'https://acme-v02.api.letsencrypt.org/acme/chall-v3/28822115860/hNTpgg'}]}
2021-09-07 08:51:27,480 - INFO - removing /tmp/tmpzh36ulcr/1ATF1lpS8BntayRI-T6PMgBWJDA_k91gJXUWLKjxAxw
2021-09-07 08:51:27,481 - INFO - removing /etc/nginx/sites-enabled/0-letsencrypt.conf
2021-09-07 08:51:27,482 - INFO - removing /tmp/tmpzh36ulcr
2021-09-07 08:51:27,493 - INFO - killing nginx process 447 with HUP

whats your server provider? do you have firewall rule that block some IPs?

2 Likes

Server is VPS. All domain records are handled through DNS.

A Record
@ 185.158.???.???

A Record
mail 185.158.???.???

MX Record
@ mail.myfirst.net. 0 1 min

If you simply shared the domain names, this could have been quickly resolved.

3 Likes

@ranch When I look at the DNS for mysecond.net it shows IP 163.43.102.93 - not the 185.* used in your example above. I do not have any guesses as to why that is but it seems a likely cause of your problem.

See:

Update: Nevermind. I had not seen @jvanasco response and thought those were his real domain names. I see now that the IP resolves to mixharbor.xyz which would have been nice to see from beginning.

2 Likes

Thanks for all the comments. It made me think and see some things I didn't notice or didn't know. I finally got everything updated. One problem was possibly the firewall, so I completely opened it. The other problem was that nginx was converting everything to https, so the second DN was getting stuck there and timing the processing out. I opened port 80 without ssh, directed everything through it and it updated everything.
As to not revealing the DN, this was just out of force of habit. It didn't work anyway because the IP was displayed. We have found in the remailer community that some people will refuse to help or communicate with remailer operators simply because they think that remailer are somehow always evil and should be outlawed. The site used to show that is was a remailer site, but now it basically says nothing.

I doubt any of those complaints relate to this forum.

2 Likes

There are very few types of sites for which we collectively as a community refuse to provide assistance (based on the direction of staff and the individual decisions of volunteers here). To the best of my knowledge, "remailer" isn't one of those. A typical example would be "red team" sites based on something like "e-v-i-l-g-i-n-x".

2 Likes

No, no problems here getting help. But how do the British say it: "Once bitten, twice wary." So I don't trust anyone on the web anymore. Not too long ago, I asked a question on a new forum that I had just joined and because they identified that the connection was coming from my remailer server in Amsterdam, the moderator summarily accursed me and banned me from the forum. I at least got a good laugh out of it! The site was being moderated by a bunch of snowflakes.

1 Like
2 Likes

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