Is there a way to set up one request to use a provided certificate and another request to not use any certificate at all in Postman?
Related
I have my API running under IIS 10. I have applied the server certificate to the site. In IIS I have also enabled SSL and I am requiring a client certificate.
The certificate has the full chain with password. In my postman request I am attaching the same certificate to my request but it always comes back 403 forbidden. If I remove the requirement for client certificate on IIS then postman request hits the API.
What am I missing? Additional folder permissions?
I already have IUSR, IIS_IUSR & the app pool
Or do I need to add something to web.confg ?
Thanks for looking
I have a REST API serving behind API Gateway.
I have a Route53-hosted zone: myAWSHostedDomain.myCompanyDomain.com
I have also created a certificate in ACM: myApp.myAWSHostedDomain.myCompanyDomain.com
The certificate has an additional domain:
myApp.myCompanyDomain.com
The cert has been issued without any problem, both domains were validated.
In the company non-AWS-hosted zone myCompanyDomain.com, I have a CNAME pointing myApp to myApp.myAWSHostedDomain.myCompanyDomain.com. It resolves OK.
I have configured a Custom Domain for that API Gateway using that certificate. The name that shows is myApp.myAWSHostedDomain.myCompanyDomain.com. Which is fine because it's the main domain for that cert.
The problem I have is that all the requests made to myApp.myCompanyDomain.com fail with a 403 Forbidden error, while those same requests on the myApp.myAWSHostedDomain.myCompanyDomain.com work just fine. The app code has nothing to do with it, a request for a favicon.ico behaves the same way.
The API Gateway endpoint is configured as a Regional one.
Could it be that API Gateway's custom domain only takes the main domain from the certificate and doesn't work with the additional ones? Is there a way to fix this?
So, the problem is that the request fails with a 403 forbidden error, because API Gateway is unable to set the correct Host header, which is required for the request to succeed.
If I do:
curl https://myApp.myCompanyDomain.com/favicon.ico -H "Host:myApp.myAWSHostedDomain.myCompanyDomain.com"
Then, it works.
Hence, the options here are the following:
Create a DNS record in Route53 for myApp.myCompanyDomain.com.
While calling the API, add a Host header to the request, with the value set as the value for the DNS record.
Create a new API Gateway where the main custom domain corresponds with the one in the API Gateway: myApp.myCompanyDomain.com work instead of myApp.myAWSHostedDomain.myCompanyDomain.com work.
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
I've got a problem with CloudFront and OCSP stapling.
I expect to get OCSP stapling for every request to my site hosted on S3+CloudFront.
It is required by design.
During the research, I found this site with similar question and this quote from documentation:
When CloudFront receives a lot of HTTPS requests for the same domain, every server in the edge location soon has a response from the CA that it can "staple" to a packet in the SSL handshake
As I understand it:
OCSP stapling works with default domain and does NOT work with custom domain until it receives some (unknown) number of requests;
OCSP stapling turns on automatically.
I see possible but not convenient solutions here:
Create a lambda function for 'viewer response' and use it for manual stapled response;
Create EC2 with Nginx and use OCSP stapling provided by it (migrate from CloudFront).
Is there any easier way to force OCSP stapling for CloudFront?
I have seen posts about this but no questions or answers that match my problem closely enough to provide a valid answer.
I can not send requests to the API through my browser.
The problem, as far as I understand is that when you send a request to the API-gateway; the browser will first send a preflight options request. this preflight request will not add any custom headers ie: x-apigw-api-id header. This then causes a 403 to be returned without even hitting the options request.
My understanding is that the client has no control over the preflight request, it is handled by the browser.
The get request works through postman and so does the options request but only if I add the x-apigw-api-id header for each request.
headers returned through postman with x-apigw-api-id added to request
{"Access-Control-Allow-Origin":"*","Access-Control-Allow-Methods":"GET,OPTIONS","Access-Control-Allow-Headers":"Content-Type,X-Api-Key,","Content-Type":"application/json"}
I remove the header I get a 403 forbidden.
Is there a workaround for this problem? perhaps not needing the x-apigw-api-id when sending an options request?
Some of the questions I looked up prior to posting:
API Gateway CORS: no 'Access-Control-Allow-Origin' header
Can't use custom Request Headers on AWS API Gateway with CORS
request api gateway cors error
AWS API Gateway No 'Access-Control-Allow-Origin' header is present
AWS API Gateway endpoint gives CORS error when POST from static site on S3
This issue can be solved by associating a VPC endpoint to your private API. This will generate a Route53 alias to your private API. From the documentation,
When you associate a VPC endpoint with your private API, API Gateway generates a new Route53 ALIAS DNS record which you can use to invoke your private APIs just as you do your edge-optimized or regional APIs without overriding a Host header or passing an x-apigw-api-id header.
https://docs.aws.amazon.com/apigateway/latest/developerguide/associate-private-api-with-vpc-endpoint.html
Based in the solution exposed by Ulrar. A private API gateway expose an option for make request without use any additional header. This URL is formed by:
https://< api-id >-< vpce-id >.execute-api.< region >.amazonaws.com
This solution is useful for CORS issues in direct browser integrations.