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.
Related
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.
Is it possible to give a application load balancer on AWS a SSL certificate, allowing allowing only HTTPS connections, if I don't want to use a custom domain?
Currently developing some internal dashboard applications, so have no need/want for a domain name attached to them.
I can only dig up info and tutorials of creating to a certificate in Cloudformation, when wanting to add a domain forwarding to the LB.
The SSL certificate has to have a valid DNS name associated with it in order to work. You need to request a certificate via ACM and then attach that to the ELB. You can configure the ELB to only have an HTTPS listener to force secure communication.
Probably not.
It's not generally kosher to issue an SSL certificate to an IP address, and since all *.compute.amazonaws.com style DNS names are floating and could be reassigned at any moment, they damn well won't issue one for them either. (Same stands for Let's Encrypt, by the way: you have to have a DNS name not issued by a provider.)
Just give your internal service a DNS name, be it something like mydashboard.internal.mycompany.com or whatever; it'll be easier to access, too.
All the documentation for Service Fabric mentions that for a production cluster you should use an X509 certificate from a trusted CA with the common name of the cluster address. The problem is I can't find any documentation on the process of obtaining the certificate. As far as I can tell for creating a certificate you need to prove you are who you say you are and to do so you either need to own the domain or expose some sort of file on the specified address.
The problem is that the url of the cluster is on a domain owned by Microsoft and my cluster is not exposed to the outside world as a website. Am I missing something? Do I have to create a web service and expose it in order to just create a certificate?
You can use any a free solution like Letsencrypt, for this it's not required to own the domain (specifically; control the DNS records). They also provide the option to respond to a HTTP based challenge, as proof of control.
To kick off the process, the agent asks the Let’s Encrypt CA what it
needs to do in order to prove that it controls example.com. The Let’s
Encrypt CA will look at the domain name being requested and issue one
or more sets of challenges. These are different ways that the agent
can prove control of the domain. For example, the CA might give the
agent a choice of either: Provisioning a DNS record under example.com,
or Provisioning an HTTP resource under a well-known URI on
https://example.com/
An easy way to get started with Letsencrypt is by using CertBot.
This needs to run on the domain, so it can respond to the HTTP challenge, which results in the issuing of a certificate for your specific cluster endpoint.
Maybe this sample project helps.
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)
I'm developing an application on Azure VM and would like to secure it by using the wildcard SSL certificate that I'm already using with my main domain. The SSL cert works with any *.mydomain.com and the application on Azure VM is accessible through myapplication.cloudapp.net
Based on the research that I've done, CNAME should be the best option to do that (I can't use A record since we need to shutdown the VMs every week and turn them back on the next week and will lose the ip addresses).
My two questions are:
How can I have myapplication.cloudapp.net be shown as subdomain.mydomain.com?
Will doing that make it possible for wildcard SSL certificate to be used for Azure application too?
How can I have myapplication.cloudapp.net be shown as
subdomain.mydomain.com?
Yes - this is just the CNAME forwarding and ensuring that the appropriate SSL certificate is installed on the server.
Will doing that make it possible for wildcard SSL certificate to be used for Azure application too?
Well as you're already exposing the Application through the VM - this should happen seemlessly.
Just a word of caution, you mention that you're using the certificate on the main domain, but haven't mentioned where you're using this. Be aware that, out-of-the-box, you can only assign one SSL per HTTPS endpoint. You can enable multiple SSL certificates on an Endpoint for Azure / IIS using Server Name Identification and can be enabled directly or automatically. If you do take this route, remember to configure your SNI bindings first, then apply the default binding - it kinda screws up otherwise.