I am following along with the following tutorial to add an SSL certificate to an API hosted with AWS API Gateway: aws-docs. I am able to successfully follow along with Generate a client certificate using the API Gateway console, resulting in the following certificate:
I am also able to Configure API to use SSL certificates by following along the prompt. The issue comes in the section that is Configure a backend HTTPS server to verify the client certificate. The instructions specify that "you must have obtained the PEM-encoded private key and a server-side certificate". Pressing "copy" retrieves the certificate, but I never got a private key when creating the certificate, and I don't see any option to retrieve the private key. How would I go about retrieving the PEM-encoded private key for a certificate created using API Gateway?
The goal of all this is to create an http request using python's requests library. Without the certificate, when posting the request I get an error which looks like:
(Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1056)'))
You can specify a certificate and private key with requests like the following according to geeksforgeeks:
result = requests.post(url, cert=('/path/client.cert', '/path/client.key')
However, as stated above, there is no obvious way to get the PEM-encoded private key. Setting the flag verify=False for the request is not acceptable for this application due to security concerns. So either a way to get the PEM-encoded private key or create the python request in another way using just the .cert file obtained using the "copy" button would be acceptable solutions for this application.
I have recently faces the same issue, when I had to create a Client Certificate, as I was following the official guide.
I also didn't receive any PEM key
Therefore I resorted to using AWS CLI
aws apigateway get-client-certificate --client-certificate-id <<your_client_cert_id>>
docs
Related
I have set up Mutual TLS authentication for my API Gateway.
I then placed my client certificate in the truststore. The file contains the client certificate, intermediate and root certificates (private CA).
When accessing the API Gateway with a browser (Chrome on Windows), browser asks me to provide client certificate. I select the same certificate as I have placed in the trust store.
API Gateway reports the following in the browser:
{"message":"Invalid client certificate chain. More than one client certificate passed"}
UPDATE: I have also tried placing only intermediate and root certs in the trust store. Same error.
UPDATE 2: The same error is also reported when accessing the API with C# code (WebClient) loading the cert from Windows cert store or from disc (pfx file).
If your trust store doesn't contain all the intermediate CA certs, then the client has to send a multi-cert chain. The TLS handshake will work fine, but somewhere there is an explicit check that disallows multi-cert chains. The status code is 400, not 403(!), and you get the "More than one client certificate passed" error.
However, if you're willing to put all the intermediate CA in the API gateway trust store, then the server should not ask the client to send intermediate certs. The client should only send one cert in this case, and API gateway should work.
So something is going wrong when API gateway matches the initial client cert against the trust store, and it's not finding the intermediate. I would check these things:
Make sure you use a specific version ID with the S3 link to the trust store. Otherwise it's hard to tell which version it's actually using, because the API gateway will not automatically pick up a new version as soon as you add one to S3. Maybe you're not using the trust store you think you are.
Your trust store should only include CA certs -- the root cert and intermediates. You said you put the client cert in there, so maybe that's causing an issue. Try taking it out.
I am trying to connect CloudFlare to API Gateway
Steps followed are:
Generated certificate in Cloudflare
Imported certificate in certificate manager in AWS
Made Full Strict in Cloudflare
in API gateway, for custom domain, I gave the domain name. Selected edge optimized and selected my certificate I imported. I am getting following error
The certificate that is attached to your distribution was not issued by a trusted Certificate Authority.
For more details, see: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#alternate-domain-names-requirements (Service: AmazonCloudFront; Status Code: 400; Error Code: InvalidViewerCertificate;
The mistake I was doing was, I was importing the certificate to the Certificate Manager. I used the .pem encoded string and imported.
What worked for me was instead of importing, I went through the " Request for certificate" process. This can be approved via DNS modification or through email approval(faster way).
The change I observed was, "Request for certificate" is AWS issued and the former is not.
Using this I generated Edge optimized custom domain which gave me a cloud front URL.
I used this to link with CNAME in my Cloudflare DNS
I'm trying to import a certificate generated in Cloudflare into AWS. Coludflare provided me with the certificate and private key, but AWS also requires a field called "certificate chain". Where can I get this value?
According to the article at https://support.cloudflare.com/hc/en-us/articles/115000479507, you can get the PEM file from https://support.cloudflare.com/hc/article_attachments/360037885371/origin_ca_rsa_root.pem and use it in certificate chain field.
I generated an SSL Certificate for my google instance cdn for the past 12 months all has been working fine, until now when after renewing the certificate with certbot when I tried to add the new certificate it fails
on the CDN console.
Interestingly the certificate works fine on https://dev.owinomart.com
but google complains that "The SSL certificate and key do not match".
When adding on the Instance, I even re-created a solo certificate for https://cdn.owinomart.com.
Creating SSL certificate "certificate-september-25-2018" failed.
Error: The SSL certificate and key do not match.
The certificate was generated for
https://dev.owinomart.com and
https://cdn.owinomart.com
It worked fine for dev but failed on cdn(which is a google CDN instance)
What could be the problem?
From your comment, it sounds like you are adding a certificate to an existing domain.
a) Please confirm that you are adding a certificate to https://cdn.owinomart.com and not deleting the old certificate resources.
From our findings, such a thing might happen when multiple keys exist, and so the Certificate Signing Request (CSR) is unable to find the correct key.
b) Please also make sure you have created a separate folder and generated a new private key along with the certificate.
I would like to point to "Creating SSL certificate resource" section of public documentation on Creating and Using SSL Certificates and would like to know which of the two scenarios you are following - that is, creating a new key with a new certificate or Creating CSR from existing certificate files?
Lastly, I am also sharing you a link on ’How do I verify that a private key matches a certificate?’ If it matches, you could manually copy the private key to the Google CDN instance.
If the modulus of the certificate and the modulus of the private key do not match, then you're not using the right private key. You can either create a brand new key and CSR and send contact support or do a search for all private keys on the system and compare their modulus.
I have set up a basic API using AWS API Gateway and I would like to link my endpoints to a service I have running on an EC2 instance (using the "HTTP Proxy" integration type). I have read that in order to lock down my EC2 server from only accepting traffic from the API Gateway, I basically have one of two options:
Stick the EC2 instance behind VPC and use Lambda functions (instead of HTTP proxy) that have VPC permissions to act as a "pass through" for the API requests
Create a Client Certificate within API Gateway, make my backend requests using that cert, and verify the cert on the EC2 instance.
I would like to employ a variation of #2 and instead of verifying the cert on the EC2 service instance itself, I would like to instead do that verification on another instance running Haproxy. I have set up a second EC2 instance with Haproxy and have that pointed at my other instance as the backend. I have locked down my service instance so it will only take requests from the Haproxy instance. That is all working. What I have been struggling to figure out is how to verify the AWS Gateway Client Certificate (that I have generated) on the Haproxy machine. I have done tons of googling and there is surprisingly zero information on how to do this exact thing. A couple questions:
Everything I have read seems to suggest that I need to generate SSL server certs on my Haproxy machine and use those in the config. Do I have to do this, or can I verify the AWS client cert without generating any additional certs?
The reading I have done suggests I would need to generate a CA and then use that CA to generate both the server and client certs. If I do in fact need to generate server certs (on the Haproxy machine), how can I generate them if I don't have access to the CA that amazon used to create the gateway client cert? I only have access to the client cert itself, from what I can tell.
Any help here?
SOLUTION UPDATE
First, I had to upgrade my version of HAproxy to v1.5.14 so I could get the SSL capabilities
I originally attempted to generate an official cert with letsencrypt. While I was able to get the API gateway working with this cert, I was not able to generate a letsencrypt cert on the HAproxy machine that the API gateway would accept. The issue surfaced as an "Internal server error" response from the API gateway and as "General SSLEngine problem" in the detailed CloudWatch logs.
I then purchased a wildcard certificate from Gandi, and tried this on the HAproxy machine, but initially ran into the exact same problem. However, I was able to determine that the structure of my SSL cert was not what the API gateway wanted. I googled and found the Gandi chain here:
https://www.gandi.net/static/CAs/GandiStandardSSLCA2.pem
Then I structured my SSL file as follows:
-----BEGIN PRIVATE KEY-----
# private key I generated locally...
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
# cert from gandi...
-----END CERTIFICATE-----
# two certs from file in the above link
I saved out this new PEM file (as haproxy.pem) and used it in my HAproxy frontend bind statement, like so:
bind :443 ssl crt haproxy.pem verify required ca-file api-gw-cert.pem
The api-gw-cert.pem in the above bind statement is a file that contains a client cert that I generated in the API gateway console. Now, the HAproxy machine properly blocks any traffic coming from anywhere but the gateway.
The reading I have done suggests I would need to generate a CA and then use that CA to generate both the server and client certs.
That's one way to do it, but it is not applicable in this case.
Your HAProxy needs to be configured with a working SSL certificate signed by a trusted CA -- not the one that signed the client certificate, and not one you create. It needs to be a certificate signed by a public, trusted CA whose root certificates are in the trust store of the back-end systems at API Gateway... which should be essentially the same as what your web browser trusts, but may be a subset.
Just as your web browser will not speak SSL to a server sporting a self-signed certificate without throwing a warning that you have to bypass, the back-end of API Gateway won't negotiate with an untrusted certificate (and there's no bypass).
Suffice it to say, you need to get API Gateway talking to your HAProxy over TLS before trying to get it to use a client cert, because otherwise you are introducing too many unknowns. Note also that you can't use an Amazon Certificate Manager cert for this, because those certs only work with CloudFront and ELB, neither of which will support client certs directly.
Once the HAProxy is working with API Gateway, you need then to configure it to authenticate the client.
You need ssl and verify required in your bind statement, but you can't verify an SSL client cert without something to verify it against.
I only have access to the client cert itself, from what I can tell.
And that's all you need.
bind ... ssl ... verify required ca-file /etc/haproxy/api-gw-cert.pem.
SSL certs are essentially a trust hierarchy. The trust at the top of the tree is explicit. Normally, the CA is explicitly trusted and anything it has signed is implicitly trusted. The CA "vouches for" the certificates it signs... and for certificates it signs with the CA attribute set, which can also sign certificates under them, extending that implicit trust.
In this case, though, you simply put the client certificate in as the CA file, and then the client certificate "vouches for"... itself. A client presenting the identical certificate is trusted, and anybody else is disconnected. Having just the certificate is not enough for a client to talk to your proxy, of course -- the client also needs the matching private key, which API Gateway has.
So, consider this two separate requirements. Get API Gateway talking to your proxy over TLS first... and after that, authenticating against the client certificate is actually the easier part.
I think you are mixing up server certs and client certs. In this instance API Gateway is the client, and HAProxy is the server. You want HAProxy to verify the client cert sent by API Gateway. API Gateway will generate the certificate for you, you just need to configure HAProxy to verify that certificate is present in every request it processes.
I'm guessing you might be looking at this tutorial where they are telling you to generate the client cert, and then configure HAProxy to verify that cert. The "generate the cert" part of that tutorial can be skipped since API Gateway is generating the cert for you.
You just need to click the "Generate" button in API Gateway, then copy/paste the contents of the certificate it presents you and save that as a .pem file on the HAProxy server. Now I'm not a big HAProxy user, but I think taking the example from that tutorial your HAProxy config would look something like:
bind 192.168.10.1:443 ssl crt ./server.pem verify required