I am trying to configure OpenAM 12.0.0 Build 8410 with OCSP validation
user. According to documentation, openam should pull ocsp responder address
from AIA of my certificate. However, in my case it does not pull, still
gives out CertPath:verify failed error. Is there any required configuration
I am missing?
A workaround would be putting all OCSP responder urls in default server and site configurations. But that fails since I do not know the appropriate separator could be used in the field. Thanks.
It turns out that the problem is associated with the version of Java I used in deploying openAM. There is no need to put the responder URL in that field as long as your certificate has AIA extension.
Related
I'm learning the process of authentication in PKi environement.
Imagine I have two web servers (example IIS) that are configured with same TLS certificate to bind websites.
Now, if I remove and add a new certificate on one of two servers. It's still have the same common name but generated with a different private key.
I wonder if having two certificate with the same common name (subject) with two different private keys will be a problem?
What information is used by the client to choose a specific public key to encrypt information?
I hope that my question is clear. Let me know if you need more information.
Many thanks for your help.
No matter how many certificates you installed to Windows certificate stores, IIS only uses the mappings in Windows HTTP API to determine the actual server certificate to use for a specific site,
https://docs.jexusmanager.com/tutorials/https-binding.html#background
If you are familiar with SSL/TLS handshake process, you can easily see in that way the browser always knows which public key to use.
Will it be a problem? The answer is maybe.
Assuming a modern browser, then the PKI works broadly like this:
the browser first uses DNS to resolve the FQDN into an address;
then the browser sends a TLS client hello to it, which contains an
SNI matching the FQDN;
the server receives the TLS client hello, checks whether the FQDN matches ones it owns, then responds with a TLS server hello containing the X.509 certificate;
the browser receives the TLS server hello, then checks that the certificate is valid;
that the SubjectAltName (SAN) field contains the FQDN (SAN has replaced
CN); and
that the certificate is signed by a CA that it trusts.
At this point the browser doesn't actually care whether you have multiple servers with multiple different certificates (which can be normal during a patch where they are being revoked and replaced).
The maybe comes afterwards, because there are a collection of HTTP extensions that can cause the browser to reject the certificate if it does not comply with what it is expecting, such as Expect-CT and HSTS.
I'm running a Windows 2012 R2 environment that hosts a website in IIS. The website currently requires a client certificate (which is validated) to access the website.
The client certificate is checked to ensure that it is valid and has not been revoked, not for identification by the operating system. If the user presents a valid certificate, the information on the certificate is used to authenticate and identify the user in the application code (the actual authentication is Forms Authentication). There is no mapping of the client certificate to an individual user (e.g. the client certificates does not map to an active directory account).
The site currently utilizes an additional piece of software to pass the client certificate to an external OCSP to verify the certificate status.
My goal is to remove that additional piece of software and be left with an IIS only (or Windows Server only) solution, but the documentation has me confused. I'm not sure if I need to install the OCSP role on the IIS server or our AD server, or if there is a way in IIS to configure a URL to check the certificate.
If the client certificate is pointing to an OCSP server in its extension, IIS will automatically validate it. You might check the CAPI2\Operational event log to see what happens during the validation.
I am trying to securing the service calls that are made from my node to other services secure. All the other services have enabled https. I tried the following methods
process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0'
which as per my understanding ignores all error so removed from the code becuase of certificates
I am using request module. where we can configure
key - provided my private key file,
cert - provided my certificate file
ca - certificate authorty chain
then it was throwing UNABLE_TO_VERIFY_LEAF_SIGNATURE
I found out that node doesn't read ca from the system.
it has its own ca chain So I included node-ssl-root-cas
which fetched latest cas from internet.
Then using ssl-analyser, i was able to find my domain doesn't have intermediate ca certificate
I downloaded that from our ca and made a ca chain and attached it to ssl-root-cas
Then i was able to make requests successfully
But Even if I remove key and cert from my request i am able to make request and get result.
How can I check my request and response are actually encrypted?
Or node just ignoring errors,
FYI, Node will use the certificate auhtorities installed on the system if you don't provide your own with the "ca" property. When you do provide your own, the system ones are ignored. This is by design, as providing your own CA likely means that you want to only trust certificates signed by your own CA. If you aren't using your own CA, you can skip setting the "ca" property. If you are, then I'm not sure why you would need to provide the full list of commonly trusted CAs as well. That seems like a pretty odd use case.
You can use the https module to make requests without providing your own key and cert. This is expected and documented behaviour. For technical reasons, when making any https requests, more specifically opening any TLS socket, the client also needs to have a private key and certificate. In the default case, the server doesn't verify the client in any way, so browsers use what's commonly referred to as a "snakeoil" certificate - a bundled self signed certificate.
The use case for providing your own key and cert when performing https requests, is when the server has client certificate checks enabled. For example, when connecting to Apple's servers for delivering push messages to iOS, you have a client certificate issued by Apple that Apple's servers uses to verify that you have access to send push messages (the certificate was issued by Apple) and which app you are sending to (the fingerprint/checksum of the certificate).
Unless the https services you talk to require specific client certificates, you're better off not setting "key" and "cert" - there's no real reason to do that.
So, in summary, you can probably skip setting all three of key, cert and ca, as the real problem seemed to be your mis-configured server (it didn't serve the CA chain).
I'm setting up a server so that only mapped certificates can get to the webservice. It is set to require SSL/Client certificates, anonymous authentication, asp.net impersonation, forms authentication, and windows authentication are all disabled. One-to-one client certificate mapping is enabled, and certs are set up on the box with an appropriate user mapping. When I try to use the webservice, I get 401.2. If I enable anonymous authentication, it works, but I don't want any old cert to be able to access the website.
I have another machine that has anonymous authentication disabled in this configuration, and it works. I'm not sure what the difference is.
I ran into the same problem, but the solution above did not solve my problem. I was configuring IIS Certificate Authentication on a subdirectory of the website, not on the website itself.
So, this is wrong:
And this is correct:
Once I moved the configuration to the root of the website, everything worked perfectly.
I found the solution at http://blogs.msdn.com/b/saurabh_singh/archive/2009/06/13/avoid-this-confusion-around-client-certificate-mapping-in-iis-6-0-7-0.aspx.
Did you issue your client certs from a Certificate Server that the clients/server trust? If you look at the "Enhanced Key Usage" property on the certificates, is "Client Authentication" one of it's properties? In IIS, is the client certificate mapping role installed (see image 1)? did you enable "Client Certificate Mapping" and map the users to the certificate? You need to import all of the client certificates and map them to user accounts here. You can remove all of the other client authentication methods when you have configured that here.
The problem ended up being the software that was calling in, not in the configuration. I'm awarding natemrice the bounty since he put in a good effort to answer what ended up being a non-question.
edit: For more information, it actually ended up being a mismatch between the cert being sent (from the local box) and the cert that was put in the oneToOne mappings. The common name was the same, but the certs were different (likely the first one expired) so the cert simply wasn't authorized.
I issued a self signed certificate on IIS 7.5, and it is working correctly if i access my website through my computer.
However, if i access the website from another computer, i get an warning saying the certificate was issued to another address.
Is this because the certificate was issued to localhost instead of the actual IP?
Or this doesn't make any sense?
Regards,
The error message you are getting is normal, assuming you do not have anything in your certificate aside from 'localhost' to identify the owner.
Your browser is performing a name check, and looking to validate the certificate that is presented with the URL you typed in. Typically, the common name of a certificate matches the hostname/DNS name of the machine. Alternatively, there can be information inside of the Subject Alt Name (SAN) extension of your certificate. There, you could specify multiple DNS names or IPAddress fields that identify your server in addition to the CN.
If you are simply performing internal testing, I would not be terribly worried about the warning you are receiving. Just keep all of this in mind when you move to production. Also, having your CA being self-signed, you may also receive trust warnings, unless you manually import your self-signed CA certificate into the trust store of the browser you are using.
Maybe this helps you: Self signed certificates on IIS 7. At the end of the article, in the section named "Adding the Certificate to Trusted Root Certificate Authorities", an alternative solution is shown, but it implies importing the certificate in the client machine, so that could be a huge disadvantage. However, it is a solution if you can't register the certificate on a Certificate Authority, an you have access to the client machine.