Does anyone know how the client certificate lookup works with XMLHttpRequest from MSXML.
When calling the setOption(SXH_OPTION_SELECT_CLIENT_SSL_CERT, ...)
I don't know the naming convention of the certificate's CN.
I have a certificate with a CN="company sa" and if I invoke it with;
setOption(SXH_OPTION_SELECT_CLIENT_SSL_CERT, "LOCAL_MACHINE\\My\\company");
everything is working correctly. But will there be a conflict if I have another certificate that has a CN like CN = "company_somethingelse"?
Thanks
The name you specify should be the full name of the certificate. There should be no naming conflict given your example.
A helpful resource:
http://download.microsoft.com/download/9/6/5/9657c01e-107f-409c-baac-7d249561629c/MSXML4SP_RelNote.htm
Specifically:
With MSXML 4.0, the client certificate can be installed in the local machine certificate store, whereas in the previous release the certificate was installed in the user's personal store. After the certificate has been installed, you can use the Certificates MMC snap-in to view the certificate. If you have multiple certificates installed, you can use the setOption method to specify the name of the certificate with a full path to the certificate.
const SXH_OPTION_SELECT_CLIENT_SSL_CERT = 3
http.setOption SXH_OPTION_SELECT_CLIENT_SSL_CERT, "LOCAL_MACHINE\My\my certificate"
The path specified refers to the registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\My\Certificates.
Related
I want to use my Google Cloud Function as a webhook endpoint for a Telegram bot - so that Telegram server makes a request to my function every time there's an update that I need to reply to. (Here's a full guide they provide for this). I have set up such a webhook at a GCF provided address, which looks like https://us-central1-project-name-123456.cloudfunctions.net/processUpdate (where processUpdate is the name of my function).
However, it looks like Telegram doesn't work with my function because of a problem with certificate. They #CanOfWormsBot created to troubleshoot this provides an error message:
⛔️ This verified certificate appears to be invalid
https://us-central1-project-name-123456.cloudfunctions.net/processUpdate
Your CN (Common Name) or SAN (Subject Alternative Name) appear not to match your domain name, please verify you're setting the correct domain for the certificate.
CERTIFICATE:
Common Name(CN): misc.google.com
Issuer: Google Internet Authority G3
Alternative Names(SAN): Too many SANS to be shown here.
Issued: 18/06/2019
Expires: 10/09/2019
What's the root cause of this issue? Does it mean that Google misconfigured certificate they use for cloudfunctions.net? Can I fix this by configuring my cloud function?
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
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
I am creating an application which requires ssl cert files. It requires .crt, .key, .ca files, but I only have .crt, .key, .pem, and .p12 files. Is the .ca file required? What exactly are those files? Is it possible to obtain .ca from .pem or .p12?
The .ca file is the Certificate Authority Root Certificate. It's the certificate that all the modern browsers have already in their resource as a trusted certificate. When your web-site is requested, your web-server will send his particular certificate + the .ca certificate... and then the browser will find out that you are indeed enrolled with that particular .ca and thus are trusted.
Without this .ca file, the browsers will fail to verify you. The communication will be encrypted and ssl'ed but the user will get a scary warning that says, this site is not protected.
If you have obtained your ssl from any of the vendors, then they will definitely be able to provide you the .ca file.
Where did you get your ssl certificate from?
For each of those file types, you can very easily wiki the types and read more about it. Just so you know, the .key file is your private key and you should take care not to lose it or to keep it somewhere unprotected. If you've actually purchased an ssl certificate, then the .key should be saved and backedu p nicely. .pem and .p12 are different containers for your certificate. Please research the topic..before asking the questions. there are many many answers on StackOverflow and other places as well for this!
I am using openssl in c to verify a certificate. Is there any way i can skip the self signed certificate error? I am getting that error for all the sites that has invalid/expired/mismatched url certificates and i am unable to detect any of the other errors.
And I use the function
SSL_CTX_load_verify_locations(ctx,0,CA_LIST)) to load CA_LIST. What does it exactly do?
The error self-signed certificate in certificate chain comes, when the root or self-signed certificate is present in the certificate list sent by the peer, but, the same is not loaded in your Trust Store.
The SSL_CTX_load_verify_locations(ctx,0,CA_LIST)) will try to load the CAs present in the path mentioned in CA_LIST.
The function prototype is int SSL_CTX_load_verify_locations(SSL_CTX *ctx, const char *CAfile, const char *CApath);
The OpenSSL Help Page Says:
"If CApath is not NULL, it points to a directory containing CA certificates in PEM format. The files each contain one CA certificate. The files are looked up by the CA subject name hash value, which must hence be available. If more than one CA certificate with the same name hash value exist, the extension must be different (e.g. 9d66eef0.0, 9d66eef0.1 etc). The search is performed in the ordering of the extension number, regardless of other properties of the certificates. Use the c_rehash utility to create the necessary links.
The certificates in CApath are only looked up when required, e.g. when building the certificate chain or when actually performing the verification of a peer certificate."
You can get more information from the OpenSSL Page here.