I registered a domain in route 53 and transferred it to another AWS Account. After that, I issue an SSL certificate and it is still pending validation state data since yesterday. Anyone can help what's the issue? why it is taking longer than expected?
Related
Trying to map a custom domain to an app deployed on Cloud Run.
Running into this issue: "Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin."
Referred to this issue:
Google Cloud Run - Domain Mapping stuck at Certificate Provisioning
Am I missing a step or should I keep waiting?
Steps I took:
Added mapping with service and domain name.
Configured a Cloud DNS Zone and updated the DNS records on the domain host.
Linked the Cloud DNS Zone to a Cloud Domain.
Verified with TXT file google-site-verification=....
Used https://dnspropagation.net/ to monitor and it seems like regions Costa Rica and Indonesia are having trouble propagating.
It's possible that it is still provisioning. But you can consider checking the following :
Make sure that your SSL's scope is global.
A-record for your domain should be properly configured.
You can try using SSL Shopper or WhatsmyDNS to monitor and check the propagation status of your domain.
I have transferred my domain from Google to AWS 7 days back. The transfer process has been completed in AWS. I have created a public hosted zone in Router 53 and the NS records present in Route 53 are matching with the NS records of my domain in AWS. Also created CNAME records pointed to the application load balancer.
I am able to access my domain inside AWS workspace and even dig command returns the results in my AWS workspace but not working in some machines outside of AWS workspace but when I use load balancer url, I am able to access the application so there are no issues with security group configuration.
Also no dig results when using this url https://toolbox.googleapps.com/apps/dig/
Am I missing something here? Any help is highly appreciated
The issue is resolved after disabling the DNSSEC in Route 53. I think I had not disabled DNSSEC in google before transferring the domain to AWS so it has transferred the DNSSEC with keys to AWS.
I'm helping a friend to migrate a website to his server, however, after the domain transfer the client's emails stopped working. I believe their email was hosted on cPanel with the old provider. What does he have to do to get the emails working again? The old service hasn't been terminated yet.
With the limited information I would recommend looking into the following.
Verify the MX records are set correctly.
Verify any subdomains they are using for example mail.domain.com or imap.domain.com etc are still pointed to the proper email server. Can verify old DNS records on previous domain server.
I would also look into the error the mail client is getting. For example is the error an auth error, server not found or something else.
You can use online tools such as https://mxtoolbox.com/ to verify that the dns records are correct.
I'm trying to request a certificate using AWS certificate manager. I'm using route53 for DNS. I go through all of the steps, and use the "create record in Route53" to create the CNAME record automatically. I have double checked the CNAME record in Route53 to make sure it is the same one that ACM expects. After doing all of this, the DNS validation times out.
I have tried this multiple times with the same result. I barely know how to use dig so I'm kind of lost on how to troubleshoot this. Thanks.
I was facing a similar issue, where i copied the whole "name" of the CNAME record (from the AWS certificate manager) to the DNS configuration for my domain. And waited a whole day without any success. Then after reading "Michael - sqlbot" answer here, i removed the .example.com from _9022ecb910c52234234234234232xxxx.example.com in my domain's DNS configuration and Amazon Certificate Manager issued the certificate in about next 30 mins.
Hope you are not making the same mistake :-)
When I switched my domain from godaddy to AWS, the Name Server records did not automatically update. I thought they would but I actually had to change them manually from the AWS console.
I had registered a domain with Route 53 and was facing a similar issue when I deleted my website's hosted zone.
The CNAME record in Route 53 was exactly as it was in ACM (no extra strings, whitespaces, etc.)
The issue was in Route 53 - the name servers associated with the registered domain were different from the name servers associated with the hosted zone.
I fixed this issue by:-
Deleting and re-creating the hosted zone.
Replacing the NS values in the registered domain with the NS values of from the newly created hosted zone.
Creating a certificate in Certificate Manager with the domain name matching with the one specified in Route 53 hosted zone.
Creating a Route 53 record from the Certificate manager wizard (which is step 5 in the wizard)
We've been using a PositiveSSL Multi-Domain Cert for some years, and that's been working fine. Under that Cert, we have, for instance:
domain1:
mail.domain1.com
www.domain1.com
domain1.com
domain2:
mail.domain2.fr
www.domain2.fr
domain2.fr
etc., with a total of 5 different domains.
Now, since we're going to expand our domain base and that the current Cert is expiring, we're looking closely at Lets-Encrypt.
Before I get into this, however, I'd like to know a couple of things:
(1)- does every subdomain (mail. www., etc.) as well as their main respective domain have to be listed in the main certificate? I'm mainly asking that because (a) that was my original understanding, and (b) the verification stage with Lets-Encrypt will differ (preferred-challenges=dns instead of by default apache-based), which will lead me to add DNS records for each domain/subdomain.
(2)- if it is indeed needed (and if I have no choice but use preferred-challenges=dns, at the time of the next Cert renewal (i.e. < 90 days), should the DNS records still have to be present? I'm asking this because last time I left the DNS records after creation, the mail server couldn't be reached anymore after the DNS propagation time. I'm pretty sure that it was because of my bad setup, but it's a risk I prefer to avoid taking.
(3)- if I'm missing here of you have a better advice to give me, let me know.
At https://websocket.email I am using the Subject Alternative Name (SAN) mechanism to handle api.websocket.email etc. I did not have to configure DNS records and used http challenges. The exact way you would do this depends on your acme client. Mine had the option listed under a config section "alternative names".
Edit: To clarify, I needed DNS records to point to my subdomains all to the same server, I am using this acme client - https://man.openbsd.org/acme-client.conf.5 and set the alternative names option. When getting my certificates I could see in my http logs, lets-encrypt fetching a single challenge file per domain to prove I own it.
In case someone has a similar issue or plan, this is what I've learned during this process:
Every domain name that the certificate will be used for has to be included. Let’s Encrypt will validate each of the domain names in the certificate.
If using DNS-01 validation, all of them will require DNS records to be added. With that, records will be required to re-validate the domains every 90 days (or whatever time frame you choose). This will require adding a new TXT record each time. Leaving the old TXT records from a previous validation will not work, the value changes each time.
There are also HTTP-01 and TLS-SNI-01 challenge types. If you already have an Apache instance running I recommend using HTTP-01.
If you don’t have a webserver on the machine that runs mail.domain1.com you can still use HTTP-01. Certbot has a feature called “standalone” mode where it can start up a small purpose built webserver to answer HTTP-01 challenges to provision a certificate.
To use HTTP or TLS-SNI validation on a non-web server, you would run something like: certbot certonly --standalone -d mail.example.com. You still need to have port 80 or 443 open in your firewall to use this method, but you need no server running on those ports. If you only want to open one port you can specify the challenge type explicitly, e.g. --preferred-challenges http to use port 80 or --preferred-challenges tls-sni to use port 443.