Solved delete *.domain.com certificate -- wildcard cert that got leftover after migration (manual dns)
-
I finished migrating my server from DO to Contabo so I had to redo the DNS to get rid of *.domain.com and add a record for each app since I had to go with manual DNS again. All is well except for checking my email on iOS. It's spitting out an error about trust/certificate and when I inspect the details section, it's showing a cert pointing to *.domain.com instead of mail.domain.com.
I assume I can find that cert via SFTP and delete it then click on RENEW ALL CERTS in my CR dashboard to recreate it. If I'm on the right track, does anyone know where those damn certs are located on the server?
Arigato!
-
@humptydumpty The cert is stored in the database and a "copy" of it is stored in
/home/yellowtent/platformdata/nginx/cert. The wildcard certs will have the file name_.domain.com.cert. I think if you first renew all certs and then go the Services -> Mail -> Restart, it will copy over the appropriate certificate to the mail service as well.This all should be automatic, but I am not 100% clear why you have changing the server meant changing the DNS.
-
@girish I had to go back to manual DNS because none of my providers are supported on Cloudron so I can't use Wildcard certs unless I have automated DNS (namesilo, contabo, dnsmadeeasy).
I did click on Renew All Certs but I keep forgetting to restart the mail service! That did it. Thanks Girish!
-
Should those two things be tied together and restart the mail service with every renew all?
-
@robi they are already tied together. But clearly there is some bug and I haven't able to figure out the root cause. This is why we keep getting this issue of mail container cert expiring. For some reason, the renew logic is not copying over certs to the mail container. Even though the code is there.
-
@girish Perhaps take a look at it from the pull perspective vs push.
Maybe even originating the refresh from the mail container side, triggering the others.
