I need to add the 'Subject' field to certs for AD. However, default setup for AD doesnt include this in the templates (Kerberos Authentication and Domain Controller Authentication).
So, when AD comes up, and then you setup CA on a server and AD starts using the CA, it grabs those default templates and doesnt have a Subject (does have a SAN however, but the app i need this work with, doesnt take the SAN).
Currently using AWS AD and CA is on a dif box from the actual DCs. AWS actually limits me from accessing the DCs directly.
I was looking at openssl to just generate a new CSR from the current cert and see if i could add the subject value in there, but i dont have the private key for the cert, so I appear to be stuck.
Answer:
Create (or copy) a template with all needs.
Certificate Authority MMC > Templates > Right-click+Manage
Then, in the new template, set the 'Superseded Templates' to add the old template(s).
Ok/Apply
Back at the CA MMC:
Right-click Templates again > New > Certificate Template to issue
choose your new template.
Also, in the 'templates' pop-up window, not sure if its relevant to "Reenroll All Certificate Holders"?
I did the reenroll bit. But, the two DCs ended up grabbing the certs on their own, i didnt have to make a cert request for them (i did on one for one of the two templates, but the other server grabbed everything on its own).
Related
I just got my custom domain name setup via AWS API Gateway, and now I have several domain names all routing to one lambda function. which just serves a webpage.
The setup looks like this:
And I have several of these with different domains that I want all to serve the same content.
Now, I'd like to add another path like /getdata or something which will just serve some data from a database instead of serving static HTML.
But when I try to add another path I get this error:
Error
Only one base path mapping is allowed if the base path is empty.
How can I have a single domain with multiple paths then?
I tried just using the wildcard path: *, and that works for multiple paths like /test or /getdata, but it doesn't work with just the domain name, and I can't tell every single user to make sure to type something in like /home everytime
Ahh I figured it out!
So, unfortunately, the page that shows you the custom domains is not where you need to be making your routes.
The correct procedure is to create an API (or use an existing API, and modify the resources) and give it a proxy resource, and a plain GET method that originates from the root path.
First, go to your API GateWay console, and create a new API.
Then once you give it a name, and choose the type (regional, or edge), it will show you the resources page
Here, you will do 2 things: Create a catch all proxy resource, and also a get resource to the root path.
Step 1: Make a catch all proxy resource:
Click Actions, and choose Create Resource
On the wizard, click Configure as proxy, and give it a name. Leave the resource path as it is. Then click create resource. The {proxy+} is notation that tells AWS that this resource should accept any path that has anything after the /. This means /test will work as well as /test/1/2/3/etc. However just / alone will not work!
Next, it will take you to this screen where you choose your integration type. We want lambda, which is the default. Make sure to select the correct region, for me the default was the right one. Then start typing in your lambda function name, and it should dynamically pop up a list of your lambda functions. select the one that you want for your application. If that doesn't work, you can copy and paste your lambda ARN from the lambda function console. Click Save.
Step 2: Make a get resource for the root path
Click the root slash at the top, right under where it says resources. Then click actions, and choose Create Method. It will pop up a little selection thing under the root slash, and there you should select GET, and then click the little checkmark.
Here, make sure to check Use Lambda Proxy Integration, and then the rest of this form should be the same as the last one you did. Just select your region, and your lambda function, and click Save.
Step 3: Deploy
Once that's done, go to actions, and choose Deploy API, give it a name for a stage, and some description, and then you are ready to attach this API to your custom domain.
Step 4: Attach
On the left tab scroll down to where it says Custom Domain Names, and create a new domain name (or attach it to an existing one if you have it)
Enter your domain name, and choose regional or edge. Then choose your certificate (there are many good guides for how to make a certificate through AWS)
Once you click save, it will look something like this:
Click Show Base Path Mappings, and then Edit.
In the path field just leave a slash, in the Destination field, choose from the dropdown the API that you just deployed. And on the right, select the stage that you made when you deployed your API.
Lastly, it will sit at initializing for a while, so while you wait for that, remember that you need to make a route53 record set for this domain, and map it to the cloudfront target URL that the API GateWay gave us. This target url looks like: www.u10dsa3s5iovdk.cloudfront.net. Copy that, and go to Route 53, Choose the hosted zone for your domain. Create a record set, and give it the same name as the domain you just created, so if you made www.example.com, in the name field of Route 53 you need to type in www. or if you made test.example.com you need to type in test. Then choose Alias: Yes, and for the Alias Target, paste in the cloudfront url from API GateWay.
When the custom domain name is done initializing, you can make calls to www.example.com as well as www.example.com/anything/else/you/want/to/put/here
Hope this helps anyone who was stuck as long as I was. Please let me know if there's anything I missed, or if something is inaccurate.
In this case you need to configure a path different to "/" for each api you need to serve through custom domain. AWS Api Gateway don't let you to serve several api into the same custom domain if you serve at least one api with no base path.
I am new in AWS and have little knowledge only for ssl. I have already bought certificate for ssl and they are like this. (file name). I buy from sslcertificate.com
But in aws panel, I saw like this to put pem value.
I am not sure which crt file I need to use. Do I need to use CSR file also? (the one that I use to have crt file).
To upload your own certificate to AWS Certificate Manager you need to provide three pieces.
Certificate Body
This is the certificate that was provided to you from your certificate authority that they have signed. This is the certificate that is unique to your website. This is what is returned to browsers when they make requests so this information is public.
In this case it is the www_test_io.crt file.
Certificate Private Key
The private key is something that you should have generated when you requested a certificate. This information must be kept secret. Keeping this secret is the key (pun intended) to how the connection is secured. Once you provide this to AWS they will never give it back to you so you may want to keep this safe on your own.
Your private key may be password protected, if it is you will have to use a command line tool to remove the password before you upload it here.
In this case the file that contains the private key was not listed, but this key is mandatory for you to be able to upload the certificate.
Certificate Chain
The certificate chain consists of the certificates that are "in-between" your certificate and the root certificate. All of this information is public, the same as your certificate. There may be zero, one, or multiple certificates in the chain. The chain is required so the clients can tie your certificate back to a root that it trusts. It is possible that not specifying a chain may work on some clients but not others so it is best to get this correct for compatibility reasons.
In this specific case you would want to put the content of the following two files in this order:
COMODORSADomainValidationSecureServerCA.crt
COMODORSAAddTrustCA.crt
All you do is take the text content of the first, copy and paste it in, and then the text content of the second, and copy and paste it right below the first.
While it is possible to also include the root certificate as part of the chain and some people do include it, it does not need to be included and is considered best practice not to actually include the root itself.
Paste www_test_io.cert contents in to Certificate body. Open the other 3 files and merge them into one (copy and paste them together) and paste that block into the Certificate chain.
You should have the private key, which was generated when you made the request. Paste it into Certificate private key
I've been using Fiddler for a couple of weeks to test an API but we're moving to Postman.
Our APIs workflow is that a device must register by using a common cert and as a response to a successful registration a private cert is issued to that device. All requests the device makes after that uses the private cert.
I'm trying to test multiple devices which means I need Postman to use 5 or 6 certs for a single domain. In Fiddler I could modify the fiddlerscript so I had an array of all the certs I intended to use. If I wanted to switch certs I opened the script and used a different index of my cert array. I'd set oSession["https-Client-Certificate"] and the request would use that cert.
In postman, I see that I can set a client cert for a particular domain. I've been able to get that to work for the global cert and running a /register request successfully. I can then change the cert and keep going. It's an annoying process if I want to change this cert after every request as I emulate multiple devices each with their own cert.
I see there's a Pre-Request Script tab. Is there a way to change the client cert in this script? If not with a Pre-Request Script, is there any other place where I can have multiple certs for a single domain and easily switch between them between requests?
I don't think that's possible, but maybe you can trick it by updating your local hosts file by creating fake local domains
104.244.42.130 cert1.api.twitter.com
104.244.42.130 cert2.api.twitter.com
104.244.42.130 cert3.api.twitter.com
104.244.42.130 cert4.api.twitter.com
104.244.42.130 cert5.api.twitter.com
Then map each local domain in postman to each certificate
cert1.api.twitter.com
cert2.api.twitter.com
cert3.api.twitter.com
cert4.api.twitter.com
cert5.api.twitter.com
and create an environment for each certificate and update the url of each request to include the {{cert}} environment. Then by switching environments you should be switching the certificate at the same time.
I'm testing a SOAP web service using Soap UI.
The WSDL location is on an external server, so I load and create a new project like this:
However, when I try to create a request, the endpoint points to localhost:
I have to manually insert the right endpoint URL for the request to work.
What could be behind this?
If you open the wsdl file in a browser or in a text editor, it will be clear that the endpoint has the same url, i.e., localhost, but not the actual one. That is the reason you are experiencing that.
This mostly happens also as developers try to use localhost while developing and it is not required/no point/does not make sense to have their hostname in wsdl unless it is a public wsdl. If QA team is using, then they will set their hostname in the endpoint, similarly for the other environments. So, you really do not have to worry about it, I believe.
In order to set the right endpoint at one place and apply for all requests( instead of changing it for each and every request), do the following:
Go to the service interface, right click and show interface viewer.
Click on Service Endpoints tab.
Click on + button.
Add the actual endpoint what you wanted
Click on Assign button, and select All requests and Test Requests from dropdown and say ok
Repeat the same if you have multiple interfaces in your project.
Save the project, and you are done.
You should be able to see the desired endpoint for all the existing test requests and even for the new one that you are going to create later.
We have been implementing GREG5.0 and using default configurations everything works fine. Once we replace the default localhost certificate in the wso2cabon.jks keystore with our own we receive "java.security.SignatureException: Signature length not correct: got 256 but was expecting 128" when we log into Store or Publisher using SSO.
We have removed the default keypair from wso2carbon.jks and added our own certificate. The password for our keystore and certificate are the same. We have updated all the configuration files per the wso2 carbon 4.4 documentation. We have updated JavaHome with local_policy.jar and us_export_policy.jar in order to allow for the longer key length.
The administrator console works great with no issues. If we change the login method of store or publisher to "basic" then it works fine. When we have the login method set to "SSO" we end up sitting on a blank page at this location https://servername/store/acs. We have the same result in the browser if we are running as a windows server or in console mode but, if we are running as a windows service then we have no error and no indication of what happened. If we are running in console mode then I get the error mentioned above spit out in the console.
I also noticed this behavior on Identity Server 5.0 when accessing dashboard.
We are running on windows.
Is there another location in WSO2 that I need to update to accomodate an increased key length?
Joe
The location I missed updating was the IdentityAlias in repository/deployment/server/jaggeryapps/store/config/store.json repository/deployment/server/jaggeryapps/publisher/config/publisher.json. Once I updated that value to match the alias of the keypair I was using in wso2carbon.jks that appeared as though it solved the keylength error and created another problem.
So now it was giving me a NullPointerException. I had provided the alias of our keypair but that was not the same as the alias for our certificate exported from our keypair that we loaded in client-truststore.jks. So I decided to set both alias' so they would match. With that change I was finally able to successfully able to access the store and publisher.
After some further testing it did not care what my keypair alias was as long as the value in IdentityAlias matched the alias of my certificate loaded in client-truststore.jks.
Hope this helps someone.
Joe