By using AWS re:Post, you agree to the Terms of Use
/AWS Certificate Manager/

Questions tagged with AWS Certificate Manager

Sort by most recent
  • 1
  • 90 / page

Browse through the questions and answers listed below or filter and sort to narrow down your results.

CDK Route 53 zone lookup brings back wrong zone ID

We are attempt to update our IaC code base to CDK v2. Prior to that we're deploy entire stacks of our system in another test environment. One part of a stack creates a TLS certificate for use with our load balancer. ``` var hostedZone = HostedZone.FromLookup(this, $"{config.ProductName}-dns-zone", new HostedZoneProviderProps { DomainName = config.RootDomainName }); DnsValidatedCertificate certificate = new DnsValidatedCertificate(this, $"{config.ProductName}-webELBCertificate-{config.Environment}", new DnsValidatedCertificateProps { HostedZone = hostedZone, DomainName = config.AppDomainName, // Used to implement ValidationMethod = ValidationMethod.DNS Validation = CertificateValidation.FromDns(hostedZone) }); ``` For some reason, the synthesised template defines the hosted zone ID for that AWS::CloudFormation::CustomResource has *something else other than the actual zone ID* in that account. That causes the certificate request validation process to fail - thus the whole cdk deploy - since it cannot find the real zone to place the validation records in. If looking at the individual pending certificate requests in Certificate Manager page, they can be approved by manually pressing the [[Create records in Route 53]] button, which finds the correct zone to do so. Not sure where exactly CDK is finding this mysterious zone ID that does not belong to us? ``` "AppwebELBCertificatetestCertificateRequestorResource68D095F7": { "Type": "AWS::CloudFormation::CustomResource", "Properties": { "ServiceToken": { "Fn::GetAtt": [ "AppwebELBCertificatetestCertificateRequestorFunctionCFE32764", "Arn" ] }, "DomainName": "root.domain", "HostedZoneId": "NON-EXISTENT ZONE ID" }, "UpdateReplacePolicy": "Delete", "DeletionPolicy": "Delete", "Metadata": { "aws:cdk:path": "App-webELBStack-test/App-webELBCertificate-test/CertificateRequestorResource/Default" } } ```
1
answers
0
votes
10
views
asked 9 days ago
2
answers
0
votes
9
views
asked a month ago

Horizontal Scaling concerns, SSL issue with NLB

note: I'm new to scaling and firstly seeking advice on the best practices for horizontal scaling **I have the following setup:** *EC2 Instances <-> ASG(created from Launch template) -> TG <-> ALB <-> TG <-> NLB* Traffic flows through NLB to ALB and finally to EC2 instances configured via ASG. note: I'm assuming the above setup is the best one to go with horizontal scaling, if not please let me know. the above setup works fine for HTTP whereas when I try to configure HTTPS, I don't see options to do so. Issue1: Target Group(TG) doesn’t allow to create one with Load Balancer type with TLS port: 443 but allows only TCP: port 80, **Question1: **how else should I redirect HTTPS traffic to ALB? note: I need NLB because ALB doesn't provide Static IPs **Question2:** wrt Static IPs: NLB doesn't allow <2 AZs which means I need to have 2 Static IPs linked to my domain? any inputs would be really helpful! **Update1:** I've configured like below: In ALB listeners: HTTP(80) gets redirected to HTTPS HTTPS(443) gets forwarded to ASG In NLB listeners: HTTP(80) gets forwarded to ALB note: ALB's public URL is added to my domain(sample-alb.domain.com) NLB's public URL is added to my domain(sample-nlb.domain.com) SSL works fine if the user enters by hitting sample-alb.domain.com whereas if the user enters by hitting sample-nlb.domain.com, it always fails with "ERR_CERT_INVALID" any inputs on why this fails? **Update2:** I've got the answer to my Issue1/Question1 on how to redirect HTTPS traffic to ALB from here: https://docs.aws.amazon.com/elasticloadbalancing/latest/network/application-load-balancer-target.html#configure-application-load-balancer-target > **Listeners and routing** > For Listeners, the default is a listener that accepts TCP traffic on port 80. Only TCP listeners can forward traffic to an Application Load Balancer target group. Keep the listener protocol set to TCP, but you can modify the port as required. > > This setup allows you to use HTTPS listeners on the Application Load Balancer to terminate the TLS protocol. so, I created a TG with TCP port 80 and listener to NLB, which redirects to ALB. (say for ex my NLB's public URL is 'nlb34323.amazonaws.com') now, when I hit my NLB's public URL with 'http://nlb34323.amazonaws.com', it does get redirected to 'https://nlb34323.amazonaws.com', but eventually fails with a timeout error. note: whereas when I hit ALB's public URL, it is working fine does it have anything to do with TLS termination as mentioned in the above documentation: > This setup allows you to use HTTPS listeners on the Application Load Balancer to terminate the TLS protocol. what am I doing wrong here?
2
answers
0
votes
11
views
asked a month ago
1
answers
0
votes
10
views
asked 3 months ago

Exam Revoked After PASSING - Bad Experience with PSI Online (AWS Solution Architect Associate Exam)

I want to report an extremely bad experience giving the AWS Solution Architect Associate (SAA-C02) exam on 01/22/2022. Apologies if this is not the right place to post this experience as I did not find any other forum to post exam-related experiences. I appeared for AWS Certified Solutions Architect - Associate (CONFIRMATION NUMBER: G81923108) on 01/22/2022. I was able to start the exam after 30 minutes of struggle in getting the PSI software loaded and working. I followed all the guidelines and requirements of the proctor and gave my full 130-minute attention to the exam. After completing the exam, I submitted the exam for the result and was very happy to see the screen "Grade: PASS. Congratulation! You have successfully passed the AWS Certified Solutions Architect .... Within 5 business days, you will receive an email stating your exam result ......" After that, I thought that the exam is now over, as I sat for another 30 seconds and did not see any notification from Proctor or any other dialog on the PASS result screen. I took the photo of the screen from my mobile to keep it for my records so that I don't lose my result and have proof. Right then I saw a screen stating your exam is terminated due to a violation of taking photos and within 10 seconds screen closed. I called PSI and explained the matter that I completed the exam and saw the result on the screen as "PASS". Only after that, I take the picture. They opened a ticket but says you need to contact AWS for resolution. This is a very frustrating situation as after 9 days, today 02/01, and I gave exam on 01/22, there is no update on the AWS certification page and also no update on the PSI website related to the result. It's not acceptable for AWS/PSI to make candidates suffer and lose belief in the certification process.
4
answers
0
votes
517
views
asked 4 months ago

AWS IoT Thing provisioning fails on Windows during certificate loading

Hello, I have a problem during the provisioning of the IoT thing using claim certificates. We are using the fleet provisioning by claim mechanism. We are following the steps described in this PDF: https://d1.awsstatic.com/whitepapers/device-manufacturing-provisioning.pdf When we start the provisioning process, we are providing the `AwsIotMqttConnectionBuilder` with the claim certificate and claim private key(which are generated in previous step). The problem comes when we are building the `MqttClientConnection` with which to make the request to the AWS IoT core for the provisioning. Here is a detailed exception: ``` Exception occurred during fleet provisioning by claim at com.iav.de.ota.provisioning.flow.FleetProvisioningByClaimFlowExecutor.execute(FleetProvisioningByClaimFlowExecutor.java:50) at com.iav.de.ota.provisioning.ProvisioningFacade.provision(ProvisioningFacade.java:60) at com.iav.de.ota.provisioning.ProvisioningFacade.provisionToDeviceManagementCloud(ProvisioningFacade.java:54) at com.iav.de.ota.provisioning.ProvisioningFacade.provision(ProvisioningFacade.java:39) at com.iav.de.ota.Main.main(Main.java:42) Caused by: software.amazon.awssdk.crt.CrtRuntimeException: TlsContext.tls_ctx_new: Failed to create new aws_tls_ctx (aws_last_error: AWS_IO_FILE_VALIDATION_FAILURE(1038), A file was read and the input did not match the expected value) AWS_IO_FILE_VALIDATION_FAILURE(1038) at software.amazon.awssdk.crt.io.TlsContext.tlsContextNew(Native Method) at software.amazon.awssdk.crt.io.TlsContext.<init>(TlsContext.java:24) at software.amazon.awssdk.crt.io.ClientTlsContext.<init>(ClientTlsContext.java:26) at software.amazon.awssdk.iot.AwsIotMqttConnectionBuilder.build(AwsIotMqttConnectionBuilder.java:502) at com.iav.de.ota.mqtt.MqttConnectionFactory.create(MqttConnectionFactory.java:44) at com.iav.de.ota.provisioning.flow.FleetProvisioningByClaimFlowExecutor.execute(FleetProvisioningByClaimFlowExecutor.java:42) ``` Going throught the error, I have found that this error `AWS_IO_FILE_VALIDATION_FAILURE(1038)` indicates that the expected claim private key/certificate is not matching the ones which we are giving it to it. So, I started going further into the issue and found that the library which we are using for reading the private key(bouncy castle) is reading a key which different than the input one. In other words, when I inspect the claim private key with Notepad and compare it with the one which the BouncyCastle has read - they are different. The problem is more interesting because this does not happen on Linux machines and only on Windows machines. I have even tried to read the claim private key as plain string from the file and pass it to the MqttConnection and this works. Unfortunately, this is not a solution because later on(after the provisioning) we are storing the real certificate and private key, for later on communication with the AWS IoT Core, in a KeyStore which we are reading with BouncyCastle, again. So, we need the library(BouncyCastle or other) in order to read the private key/certificate in any moment of the execution of the progam(either during the provisioning or later on during the other AWS IoT Core calls with the real certificates). Forgot to mention, the claim private key and claim certificate are stored in PEM format. Could you tell me what can be done here? Is there any AWS supported library for reading the claim private key/certificate without using BouncyCastle? Any suggestions here are welcomed because we are stucked and the requirements are that each AWS IoT Things will be running on Windows OS. Thanks a lot, Encho
1
answers
0
votes
15
views
asked 5 months ago

Why is HTTPD failing to start? Why is TLS failing to start? Missing certificate key is not missing!

For context, I followed this tutorial to configure SSL/TLS on an EC2 instance: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2.html Everything was working fine, I've installed a web application (Drupal 9) from composer-based repo, maintained my code, fine. I updated some packages with yum, update php, etc. I attempt to start Apache: ``` [ec2-user@ip-172-31-32-159 ~]$ sudo systemctl restart httpd Job for httpd.service failed. See "systemctl status httpd.service" and "journalctl -xe" for details. ``` I check `journalctl -xe` The important part appears to be: ``` -- Unit httpd-init.service has begun starting up. Jan 10 00:10:41 ip-172-31-32-159.us-east-2.compute.internal httpd-ssl-gencerts[9368]: Missing certificate key! Jan 10 00:10:41 ip-172-31-32-159.us-east-2.compute.internal systemd[1]: httpd-init.service: main process exited, code=exited, status=1/FAILURE Jan 10 00:10:41 ip-172-31-32-159.us-east-2.compute.internal systemd[1]: Failed to start One-time temporary TLS key generation for httpd.service. -- Subject: Unit httpd-init.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit httpd-init.service has failed. -- -- The result is failed. ``` Here is something interesting. I check `vim /etc/httpd/conf.d/ssl.conf` At line 100 is `SSLCertificateFile /etc/pki/tls/certs/localhost.crt` Okay, very good. The interesting thing is if I rename the file `sudo mv /etc/pki/tls/certs/localhost.crt /etc/pki/tls/certs/localhost.crt.bak`, and then try to start httpd `sudo systemctl start httpd`, returned is `Job for httpd.service failed because the control process exited with error code.` Checking `journalctl -xe` again, we recieve a different error: ``` -- Unit httpd.service has begun starting up. Jan 10 00:42:56 ip-172-31-32-159.us-east-2.compute.internal httpd[9841]: AH00526: Syntax error on line 100 of /etc/httpd/conf.d/ssl.conf: Jan 10 00:42:56 ip-172-31-32-159.us-east-2.compute.internal httpd[9841]: SSLCertificateFile: file '/etc/pki/tls/certs/localhost.crt' does not exist or Jan 10 00:42:56 ip-172-31-32-159.us-east-2.compute.internal systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURE Jan 10 00:42:56 ip-172-31-32-159.us-east-2.compute.internal systemd[1]: Failed to start The Apache HTTP Server. ``` Renaming localhost.crt to localhost.crt.bak changes the error, breaks the link, and SSLCertificateFile appropriately does not exist. Changing localhost.crt.bak to localhost.crt restores the SSLCertificateFile link, and changes the error back to claiming there is a missing certificate key, when we can see it there: ``` Jan 10 00:47:07 ip-172-31-32-159.us-east-2.compute.internal httpd-ssl-gencerts[9884]: Missing certificate key! ``` What is going on here?
0
answers
0
votes
5
views
asked 5 months ago

How can I serve CloudFront assets to a naked domain I manage with a non-AWS DNS provider?

Hi all! Summary: Our DNS provider, GoDaddy, does not support apex ("A") DNS records pointing to non-static IPs. We want to serve our AWS CloudFront assets to our domain's naked domain, but CloudFront gives us a url, not a static IP. Here's the current state of our setup: * We own a domain, let's call it domain.com, through GoDaddy * We manage the DNS for this domain through GoDaddy * We store our website assets in AWS S3 * We use AWS CloudFront to serve the website assets from that S3 bucket * CloudFront gives us a url, like xyz123.cloudfront.net, that the assets are served from * CloudFront does not give us a static IP address * We use AWS Certificate Manager to apply an SSL certificate to both our naked domain "domain.com" and www subdomain "www.domain.com" * The SSL certificate is applied to the CloudFront configuration * We have a CNAME DNS record pointing the www subdomain to the CloudFront url * ie. navigating to www.domain.com properly gets served the CloudFront assets, and since we have the SSL certificate applied to this domain and the CloudFront configuration we don't encounter any SSL issues. * We use a feature on GoDaddy called Forwarding to redirect any http://domain.com naked domain requests to http://www.domain.com * Our CloudFront has a “Viewer protocol policy” of “Redirect HTTP to HTTPS”, so http://www.domain.com thereafter gets converted to https://www.domain.com Current issues that we would like to solve: * We want https://domain.com to serve the CloudFront assets. * This may involve serving CloudFront assets directly from that url or redirecting it to https://www.domain.com * We can't serve the assets directly with our current setup because GoDaddy's DNS management does not support apex records pointing to urls - it must point to an IP, and we don't get a static IP from CloudFront * In past iterations, we’ve used GoDaddy’s Forwarding feature to attempt to redirect https://domain.com to https://www.domain.com, or even http://www.domain.com, but GoDaddy’s Forwarding feature does not support HTTPS requests. * The Forwarding feature changes the A record to point to GoDaddy’s proxy server, and that proxy server does not have our SSL certificate installed, so we were getting SSL warnings. * We own another domain, let's call it other-domain.com, and we would like to redirect all requests to both the naked domain and the www subdomain (http and https) to https://www.domain.com. * We ran into a similar issue here: we can’t use GoDaddy Forwarding here to reroute https requests - it spawns an SSL warning. We imagine the solutions may be: 1. Get a static IP from CloudFront. Is this possible? And are there time, energy, and money costs associated with this? 2. Use our own redirect server. We could potentially manage a simple, say, AWS EC2 instance that uses an nginx or Apache server that redirects requests to https://www.domain.com. We could point the naked domain to the IP of the EC2 instance, and have our own SSL certificate installed there. We're not crazy about this because it adds another node of complexity that we manage. We would be more interested in this option if there was some AWS service that gave us SSL-enabled redirect capabilities out of the box - does that exist? 3. Change our DNS provider from GoDaddy to AWS Route53. As far as we can tell Route53 allows apex DNS records to point to urls instead of requiring them to point to IP addresses, which means we can just point an A record for domain.com to the CloudFront url. We're also not crazy about this because migrating DNS providers is a lift, and we have many other domains managed through GoDaddy as well. Any and all feedback / suggestions is welcome. Thank you!
1
answers
0
votes
44
views
asked 5 months ago
  • 1
  • 90 / page