Certificate Authorities - JINIT 1.1.8.19

HI,
We are intending to deploy our Forms application (at mutiple client intranets, and internet as ASP), and wish to automate the procedure of deploying and cerftifying JAR components, intergrating with the client machine.
We have followed the most helpful document on JAR signing etc for JINIT 1.3, but for our current release we intend to use JInit 1.1.8.19 (and 9iAS Forms Services Release 1 - patchset 10). In order to aid customer confidence in the Java code, and automate the recognition of the signing identity of the code, we intend to purchase a Certificate Authority certificate.
My questions are as follows :
1. Which Certificate Authorities public keys are currently recognised by the identity.obj delivered by default in JInit 1.1.8.19 ?
2. Currently, I appear only to be able to obtain a certificate conforming to the 1.3 JDK. Will these type of certificates enable to deploy using 1.1.8.19 ? For your information, I attach copy of my question and response from Verisign.
Issue Details & Information
Code Signing: Sun Java
The nature of the issue is:
Need additional information on or are unable to sign code
Other issue Specified:
Additional Information surrounding the issue:
Hi,
Wish to purchase Code Signing ID, but signed Applet will be deployed using
1.1.8.19 version of the Java Soft plug-in (actually packaged by Oracle as
JInitiator). We have been using the "javakey" commands to create and sign
using a self-signed certificate.
Will the available certificate allow us to deploy using 1.1.8.19 ?
Thanks
Reply
Dear VeriSign Customer,
Special requirements: Tools/SDK version:
The Java Applet needs to be written using the Java 2 JDK v1.3. (J2SEv1.3 is
the first JDK from Sun with an RSA signature provider). Download available
at http://java.sun.com/j2se/1.3/
Java Plug-in v1.3: This allows web page authors to direct Java applets on
their web pages to run using Sun's Java Runtime Environment (JRE) instead of
the browser's default run time environment and hence be confident that the
applets are executed with full support for all of the features and
capabilities of Java 2 SDK 1.3 in Microsoft's IE 4.0 or later, and
Netscape's Navigator 4.0 or later on various Win32 platforms and Solaris
platforms.
Download available at: http://java.sun.com/products/plugin/index.html.
Thank you,
Jennifer
VeriSign Customer Support
As ever, your continued assistance is appreciated.
Regards
Marc Ludwig

HI,
Thanks for the response.
For your info, the main reason why we are currently planning to use 1.1.8.19, is purely because all testing / QAT / performance monitoring, has been performed using this version. We are really close to our first expected delivery date and would prefer to stick with what we have. Also, customers have expressed a desire for code to be signed using Certifcate Authority verified methods, rather than self-signed (I don't think this a technical decision, more one of marketing). Also as the Oracle path is to begin to certify directly to Java Soft 1.4..., I'd prefer to make the jump at that stage (particularily considering the supposed solving of the whole authentication issue within this release).
On a slightly un-related note, my personal experience of JInit 1.3, has been that performance (and memory usage on the client machine) appears to be worse / higher than 1.1; but this may just be me. Have you any expereince using the 1.3 plug-in ?
Thanks again for your interest.
Regards
Marc Hi Marc
From what I read from your mail from VeriSign you may be forced to upgrade to JInitiator 1.3, if you must use Certificate Authorities. I understand your need to deploy, what you have been using in your test environment; but in this particular case, if CA is a requirement, I guess the best thing you can do is to deploy on JInit 1.1 now using self-signed certificates and then start using JInit 1.3 in your test environment ASAP. I do not know, if any CA's still issue Java1.1 certificates, sorry.
To be honest, I'm waiting for JPI 1.4 certification also; unfortunately, I couldn't wait for this because of customer requirement for Forms9i, and JInit 1.3 actually seems to run OK in my experience - the smallest machine I've run it on is a PentiumII 350 Mhz with 128 MB RAM and Win98, where I really couldn't spot any difference regarding performance. I have actually tested the JPI 1.4.1 also - and it seems to have kind of the same cerficate problem, which Duncan Mills mentions in his recently released whitepaper - but of course this was only a quick test, since I would never actually deploy the 1.4.x JPI as long as it isn't certified from Oracle - and also I do know from other tests, that there may be some incompatibility issues between Java2 1.3 and 1.4...
Sorry I couldn't be of more help - but if you ever should deploy JInit 1.3, eventually maybe even Forms9i, I'd be more that happy to share further experiences regarding these matters.
Regards,
Jacob

Similar Messages

Computer certificates expiring within 6 weeks disappearing from machines when computer certificates from two certificate authorities are present

2008 R2 single tier enterprise certificate authority with root certificate expiring within 6 weeks, also domain controller
2012 R2 single tier enterprise certificate authority with root certificate valid for more than the next year, also domain controller
Both servers are approved as certificate authorities for the domain and can issue computer certificates using the computer certificate template. There is a group policy object applied to all workstations that contains an automatic computer certificate request,
but the actual "certificate services client auto-enrollment" element is "not configured". This process seems to work like a round robin in that computers with no certificate can wind up with a certificate from either certificate
authority. I need all PCs to have both certs for a DirectAccess migration. I have successfully used SCCM to ensure all PCs have both certificates using compliance rules and a script using certreq.exe.
A machine will keep both certs until the older computer certificate moves into the 6 week window of expiration, then it gets purged. I have observed this behavior for over a month, even when the CA root certificate wasn't so close to expiring. I
can't figure out what setting is triggering the purge, but need to stop it. Maybe it's coming from default settings in local machine policy for an element that should be disabled in the group policy object supplying the automatic certificate request?
The worst part of this issue is that I can't recreate the purging behavior with gpupdates or restarts on my test machines.

You should not be using Automatic Certificate Request Service (ACRS) for this - it was designed for Windows 2000 and is generally deprecated. Secondly, the reason it is acting like a round-robin as you describe it, is that templates are generally configured
to attempt to renew within 6 weeks of their expiration. Since the 2008 R2 CA is expiring within 6 weeks, it cant issue anything longer than its own remaining lifetime. It is a well known issue that issuing a certificate within the renewal period will cause
problems.
What you should do it use AutoEnrollment and issue a certificate with a very small renewal period (1 week perhaps) by creating a custom V2 template and issuing that from your 2008 R2 CA. Then on the 2012 R2 CA you will need ANOTHER template, as the computer
will only enroll for a certificate from each template. This one can be configured with a normal lifetime and renewal period.
Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. Connect with Mark at http://www.pkisolutions.com

Safari, Proxy Authentication, and Certificate Authorities ( for https )

A recent update to Safari has caused it to not work with our proxy authentication. It will not provide authentication details when looking up SSL certificate authorities, causing certificate errors on all https:// websites. All other traffic (http, https if certificate is bypassed, plugins, etc.) seem to work just fine. Is anyone else having this problem? If so, is there a fix?
It occurs on Mac and PC. I am using SquidGuard with NTLM authentication. All other browsers on our system (IE x.x, FireFox, Chrome, Opera ) don't have this issue.

I have the same problem and it's frustrating as can be.
What happens to me is that When I bring my laptop to work, and put it on the work network and launch Safari, Safari informs me that each of my plugins is invalid and then uninstalls them - I'm effectively not able to use any plug ins at work, and I have to go hunt them down when I get back home (for reference, The extensions are still physically in \users\me\Library\Safari\Extensions - so when I get home I can just double click on all of them)
I opened a case with apple and I encourage you to do the same. Perhaps if enough users complain they will find a gentler way to work with it.
They had me do a capture and after analyzing it said it was an issue with the work network and not being able to valdate the extensions.
It sounds like the same issue you have - as my work network uses a proxy as well.
The rep suggested that I use a different browser at work, but I'm so used to clicking safari, that I do it out of habit.
I really like Safari, and hope they get it fixed - Safari may not get respect in the windows world, but it's really a great browser - especially on a laptop where screen real estate is limited (where I often hit command-shift-\ to hide the address bar to see more of the page)
-Jack

Enterprise subordinate CA does not show up in certificate authorities list

After much discussion I decided the best approach was to clean eveything up and start over. I went through the KB on decommissioning an enterprise CA and Subordinate CA, install a new standalone root, and a new enterprise subordinate CA. Everything appeared
to be working with one exception. The new Enterprise Subordinate does not show up in the Certificate Authorities section of Public key services in AD Sites&Services. It does show up in AIA, CDP and Enrollment services. The standalone root is trusted and
I set up group policy with the certificate of the Enterprise Subordinate as a trusted intermediate. The templates were configured also as well as autoenrollment for computers but so far only the DCs and my workstation has received certificates. I am sure I
am missing something but after 100s of pages and artcle after article I don't see it. I ran the certutil -viewstore query and it doesn't see it either and it doesn't tell me how to fix it. Also, what is the deal with case; it seems no matter how careful I
was with upper and lower case letter AD did what it wanted and my published CA name looks like I can't figure out hows caps lock works.
Thanks in advance
[email protected]

yes, it is possible. However, you will need to make some modifications on root CA:
certutil -setreg ca\dsconfig "AD Configuration naming context"
certutil -setreg ca\dsconfigdn "AD Configuration naming context"
certutil -setreg ca\dsdomaindn "AD Forest root domain DN"
AD configuration naming context is (usually) CN=Configuration, DC=rootdomainname, DC=domainsuffix.
To extend Root CA CRL validity, in the Certification Authority MMC, select properties of Revoked Certificates folder and specify validity period (something about 6-12 months). Make sure that Delta CRLs are NOT enabled. Save settings and restart certificate
services.
Then you should republish all CRLs and publish CRL to Active Directory:
certutil -dspublish -f path\RootCAcrl.crl
My weblog: http://en-us.sysadmins.lv
PowerShell PKI Module: http://pspki.codeplex.com
Windows PKI reference:
on TechNet wiki

I have a long list of Certificate Authorities, many of which are overseas, e.g. Netherlands, Turkey, China, and many others. Should I delete them?

I have a long list of Certificate Authorities (about 280), many of which are overseas, e.g. Netherlands, Turkey, China, and many others that are unknown to me. They do not appear to be related to any websites I visited. Are my emails compromised in terms of privacy? Should I delete them? Why do I need so many certificate authorities?

Sure delete them... but when you get email or try and open a web page that has a certificate from them you will not be able to open the mail or the web page without issues or making manual decision to trust the authority in question. The geographical location of the certifying authority is of no relevance.
The now defunct Mozilla Messaging used a certifying authority in Israel for it's certificates (Start) so if someone had deleted that from their settings in a fit of xenophobic housekeeping they would not have been able to open their web sites or read mail from their employees without problems.
Certifying Authorities form a chain of trust. They on the whole certify one another, but at the top of the certification pyramid/s there most be someone or group of someones who the program simply "trusts" to certify. Hence programs have a long list of pre approved companies that are allowed to issue certificates. These lists are constantly updated and should there be a serious security issue such as one of the authorities being compromised. The people at Mozilla will update or revoke that authorities trusted status.

How do I restore default SSL security certificates/authorities/servers?

A website I visit often was having SSL certificate issues. I did not know what certificate I needed to remove in order to get it working again... So I removed ALL of my security certificates/authorities.
I did not realize it would be near impossible to restore them.
Now every website I go to is "untrusted" and I need to confirm a security exception.
How do I restore the certificates/authorities to the default state?
I tried removing firefox and reinstalling, but that did not fix it.
Any help would be greatly appreciated. At this point I'm tempted to just switch to Chrome or another browser.

See '''cor-el''' reply - Solution Chosen
https://support.mozilla.org/en-US/questions/878694
thank you

Digital Signatures and Certificate Authorities

My users are wanting a way to sign PDF documents, and have them verified for internal and external receipients. We are currently using Acrobat 9 Standard. I know you can create signatures and 'self-sign' them, but those are only trusted if the receipient manually adds them to their 'Trusted' people.
From my reading, it looks like we need to purchase a third party code signing certificate, such as the following: http://www.verisign.com/code-signing/
My question is, what do we need to do to make that certificate availbable to my users to use for their signatures? I'm having a hard time finding documentation on this part.

Here's a good starting point for understanding how CDS and AATL work with Acrobat and Reader: http://learn.adobe.com/wiki/display/security/Digital+Signatures+101
Another option you should look into is Adobe EchoSign: http://blogs.adobe.com/acrobat/tag/echosign

Verisign Class 3 Extended Validation SSL CA missing from the Certificate authorities

Is Mozllia still including Verisign Class 3 Extended Validation SSL CA in their downloads? When I do fresh installations of version 3.6.13 and 4.0 Beta I am getting a sec_error_unknown_issuer and it doesn't appeare to have that CA in Certificate Manager.

That is an intermediate certificate that web servers need to send. Firefox only comes with the VeriSign root certificates and not with all other intermediate certificates.
See https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR1130
If the server isn't sending the certificate and you haven't visited a website that sends it then you need to install it yourself.<br />
You can visit this web page to make Firefox store that certificate:
* https://www.verisign.com/repository/index.html
More:
*https://www.verisign.com/support/verisign-intermediate-ca/secure-site-intermediate/index.html (VeriSign Class 3 Secure Server CA - G2)
*https://www.verisign.com/support/install2/intermediate.html (VeriSign International Server CA - Class 3)
*https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR1514 (VeriSign International Server CA - Class 3;VeriSign, Inc.)

Wireless clients not trusting well-known Certificate Authorities by default??

I'm using PEAP-MSCHAPv2 for wireless authentication. The radius server is a Windows 2008 server running NPS. The clients consist of a bunch of laptops (mostly running Windows). Not all of these laptops are members of Active Directory. So, pushing any type of policy out to all clients isn't feasible (ie. using a private PKI and using AD to push the server cert and wireless config to all domain members). So we decided to use a public PKI and obtained a certificate for our radius server through a well known CA. So far, so good.
When clients to go connect, they still get a nasty warning saying:
--START--
The credentials provided by the server could not be validated. We recommend that you terminate the connection and contact your administrator with the information provided in the details. You may still connect but doing so exposes you to security risk by a possible rogue server.
Details
Radius Server: $radius
Root CA: $ca
The server "$radius" presented a valid certificate issued by "$ca", but "$ca" is not configured as a valid trust anchor for this profile. Further, the server "$radius" is not configured as a valid NPS server to connect to for this profile.
--STOP--
(I replaced the actual radius server name with $radius and the CA with $ca).
Doing a little digging, it appears this is just the expected behavior of the Windows wireless client??? What's the point of getting a signed cert by a well-known CA if the client is still going to get a nasty warning like this?
Web browsers certainly don't behave like this. The only difference between a web browser and the wireless client is with a browser, you're always going after a URL (ie, you can match what the browser wants to connect to versus what the CN on the server's cert comes back with) whereas on the wireless client, you generally won't know the radius server you're going to authenticate against. But, in either scenario, the server's cert is signed by a well known CA.
I found a nice post that mentions this, but no solution:
http://social.technet.microsoft.com/Forums/en/winserverNIS/thread/26886f09-e424-48da-9ecc-cf7efd9dccc0
Well, I suppose a solution is to manually configure the client to trust certs issued by the CA and/or configure my radius server in the connection profile. But that requires configuring each client. And there's no way we can use AD to push a policy/cert to all clients.
So my questions are:
-is this really the expected behavior?
-so browsers generally trust the default CAs whose certs are stored on the OS by default but the wireless adapters don't?

This is a limitation of the Windows wireless client.
http://support.microsoft.com/kb/2518158
Somewhere was an artical the described that Microsoft wirless client does not trust public root CAs by default. Using a 3rd party utility like Intel Pro Set trusts all the 3rd party root CAs by default so you dont get this message.
Please respond to Microsoft and voice your problem maybe they will fix their wireless client to trust public root CAs.
Justin.

In Preferences - Advanced - Encryption - View Certificates - Authorities, the "Delete or Distrust" Option appears to be inoperative (recently been hacked).

I attempted the previous steps in an effort to delete some suspicious looking certificates following unusual experiences online using WiFi without success. I "deleted" a number of different certificates and then selected "ok" only to see them all reappear again, and again. since experiencing a recent hacking event, I have also enacted a number of other steps involving our WiFi, Computer, and e-mail provider in addition to the Firefox Browser. Any thoughts?

You can't remove build-in root certificates.<br />
You can only remove the trust bits to prevent Firefox from using the certificate as root certificate and that is what Firefox does in such a case.<br />
You can verify that by clicking the Edit button.

Is there a list of valid system root certificate authorities for a vanilla OSX (Lion, Mountain Lion) installation?

I'm looking for a current list of valid CAs to compare to those in system keychain. thnxs!

You can dump all of the root certificates with:
security find-certificate -a -Z /System/Library/Keychains/SystemRootCertificates.keychain
Here's a script I wrote a while ago as part of an attempt to mitigate CAs that I didn't want to trust... I work in a government environment, so it seems silly to trust CAs from China and Russia, as well as an assortment of other oddball countries. Maybe it will help you find what you're looking for:
#!/bin/sh
if [ -f /tmp/rootcerts ]
then
rm -f /tmp/rootcerts
fi
if [ -f /tmp/rootcerts.sh ]
then
rm -f /tmp/rootcerts.sh
fi
if [ -f /tmp/ccs ]
then
rm -f /tmp/ccs
fi
echo ""
echo "Script generated at /tmp/rootcerts.sh"
echo ""
security find-certificate -a -Z /System/Library/Keychains/SystemRootCertificates.keychain | sed 's/^\ \ \ \ //' | grep -v '^keychain\|^class\|^attributes\|^"cenc\|^"ctyp\|^"hpky\|^"issu\|^"alis\|^"skid \|^"snbr\|^"subj'| sed 'N;s/\n/@/' | sed 's/"labl"\<blob\>\=//' | sed 's/^SHA-1\ hash\:\ //' | sort -t'@' -k2 > /tmp/rootcerts
while read line
do
SHA=`echo $line | cut -d'@' -f1`
NAME=`echo $line | cut -d'@' -f2`
NAME2=`echo $line | cut -d'@' -f2 | sed -e 's/^\"//' -e 's/\"$//'`
security find-certificate -c "$NAME2" /System/Library/Keychains/SystemRootCertificates.keychain >/dev/null 2>&1
if [ "$?" -eq "0" ]
then
    APPL=0
    security find-certificate -c "$NAME2" /System/Library/Keychains/SystemRootCertificates.keychain | grep [Aa]pple >/dev/null 2>&1
    if [ "$?" -eq "0" ]
    then
      APPL=1
    fi
    DOD=0
    security find-certificate -c "$NAME2" /System/Library/Keychains/SystemRootCertificates.keychain | grep DoD >/dev/null 2>&1
    if [ "$?" -eq "0" ]
    then
      DOD=1
    fi
    CTRY=`security find-certificate -c "$NAME2" -p /System/Library/Keychains/SystemRootCertificates.keychain | openssl x509 -text | grep '^\ *Issuer:' | tr -s ' ' | cut -d' ' -f3 | sed -e 's/^C=//' -e 's/,$//' | sed 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/'`
    case $CTRY in
      [A-Z][A-Z] ) if [ "$APPL" -eq "1" ]
                   then
                     echo "# $NAME - APPLE" >> /tmp/rootcerts.sh
                     echo "#security delete-certificate -Z $SHA /System/Library/Keychains/SystemRootCertificates.keychain" >> /tmp/rootcerts.sh
                     echo "" >> /tmp/rootcerts.sh
                   elif [ "$DOD" -eq "1" ]
                   then
                     echo "# $NAME - DoD" >> /tmp/rootcerts.sh
                     echo "#security delete-certificate -Z $SHA /System/Library/Keychains/SystemRootCertificates.keychain" >> /tmp/rootcerts.sh
                     echo "" >> /tmp/rootcerts.sh
                   else
                     echo "# $NAME - $CTRY" >> /tmp/rootcerts.sh
                     echo "security delete-certificate -Z $SHA /System/Library/Keychains/SystemRootCertificates.keychain" >> /tmp/rootcerts.sh
                     echo "" >> /tmp/rootcerts.sh
                   fi ;;
      * ) echo "# $NAME did not return a valid country code" >> /tmp/rootcerts.sh
          echo "security delete-certificate -Z $SHA /System/Library/Keychains/SystemRootCertificates.keychain" >> /tmp/rootcerts.sh
          echo "" >> /tmp/rootcerts.sh ;;
    esac
else
    echo "$NAME could not be read" >> /tmp/rootcerts.sh
    echo "" >> /tmp/rootcerts.sh
fi
done</tmp/rootcerts
ALL1=`security find-certificate -a /System/Library/Keychains/SystemRootCertificates.keychain | grep labl | wc -l`
echo "There are $ALL1 certificates in SystemRootCertificates"
echo ""
ALL=`grep '^security' /tmp/rootcerts.sh | wc -l | sed 's/^\ *//' | grep -v '^$'`
echo "There were $ALL certificates read and dumped into rootcerts.sh"
echo ""
NOCODE=`grep '^#.*did not return a valid country code' /tmp/rootcerts.sh | wc -l | sed 's/^\ *//' | grep -v '^$'`
echo "There were $NOCODE certificates that did not return a country code"
echo ""
grep '^#.*\ \-\ ' /tmp/rootcerts.sh | sed 's/^#\ .*\ \-\ //g' | sort | uniq > /tmp/ccs
for i in `cat /tmp/ccs`
do
NUM=`grep $i$ /tmp/rootcerts.sh | wc -l | sed 's/^\ *//' | grep -v '^$'`
echo "There were $NUM entries in country code $i"
done
if [ -f /tmp/ccs ]
then
rm -f /tmp/ccs
fi
if [ -f /tmp/rootcerts ]
then
rm -f /tmp/rootcerts
fi

Who is warranting the Root Certificate Authorities

My mac has 218 root CAs from many countries, including US DoD, various small enterprises, at least one of which famously lost some of its private keys.
Who is responsible for the trust put into these entities, which provide the assurance around https connections?
Is it me as a user who is supposed to check each one out?
Apple as the original installer?
The Apple legal entity in my jurisdiction?
afaict, none of my https based communications are actually very confidential, nor tamper proof: including banking transactions. Although it's becoming common for banking authentication to involve physical tokens, it still looks to me like confidentiality is at risk and there is at least an opportunity to hijack in flight interactions.

http://www.bbc.com/news/technology-28208905
http://contextis.com/resources/blog/hacking-internet-connected-light-bulbs/
http://www.theregister.co.uk/2014/07/07/wifi_enabled_led_light_bulb_is_hackable_ shocker/
Some on security from NIST...
http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf

Asking specific client certificate (not certificates trusted by authority)

As I understand from what I read so far, during the handshake negotiation for two way ssl, the server sends the client a list of trusted certificate authorities and say to the client: "hey, those are the authorities I trust. send me a certificate that can be verified by one of them".
I also read how you can customize SSLSocketFactory to, on the client side, look for a specific certificate alias (http://www.ibm.com/developerworks/java/library/j-customssl/). I would like to move this idea further and ask for specific certificates depending on what resources the user is trying to access.
For example:
Let's suppose I have two resources on my server called "bobPrivateStuff" and "alicePrivateStuff". I also have a certificate authority who can validate both Bob and Alice certificates on a custom trust keystore. In a regular scenario, the server will ask for a client certificate and will accept either Alice or Bob certificate, as both can be verified by the custom trust.
But what if Alice can't access "bobPrivateStuff"? What if when trying to open a connection, to say http://myserver.com/services/bobPrivateStuff, the server asks specifically for Bob's certificate? Can I setup the handshake in a way it will actually ask for Bob's certificate instead of only just "any certificated trusted by this CA"?
And what piece of information could be used to distinguish one certificate from another? Is the serial number unique between multiple certificates? Is this pushing the envelop too much and trying to use SSL for more than what it is intended for?

I agree 100%. It's just that we want to use certificates to validate the client's identity (instead of relying on username/password).Fine, that's exactly what SSL & PKI will do for you.
It might not be elegantBut it is!
See my point?Of course I see your point. SSL already does that. I said that. You agreed. I agree. What it doesn't do is the authorization part. Because it can't. It isn't meant to. You are supposed to do that.
Instead of the server asking for a specific certificate, it justs checks if the certificate sent by the client has access to the resource.Not quite. It should check if the identity represented by the client certificate (Certificate.getSubjectX500Principal(), or SSLSocket.getSession().getPeerPrincipal()) has access to the resource.
This way, we can leave the server untouchedNo you can't. The server has to get hold of the client principal after the handshake and authorize it against the resource.
if Bob wants to access some resources, Bob has to prove he is who he says he is.You're still confused. That's authentication, and SSL already does that for you. SSLSocket.getSession().getPeerPrincipal() returns you the authenticated identity of the peer. The server then has to check that that identity can access that resource. This is 'authorization'. You can't automate it via keystores and truststores. That's not what they do and it's not what they're for.
So I think it is perfectly plausible to do this kind of verification on the server side (i.e. "hijack" a certificate sent to validate the ssl handshake to also verify if the user has the correct privileges).There's no 'hijacking' about it, but you're concentrating on the certificate instead of the identity it represents. A client could have a large number of certificates that all authenticate the same identity. You need to think in terms of authorizing Principals to access resources.

ACS 5.3 / Self Signed / Certificate base auth

Hello,
Our ACS (5.3) has self signed certificate, we have exported it and declared it in Certificate Authorities.
We have exported it to have a Trusted Certificate for client machine.
This certificat has been installed on a laptop.
The wlc is successfully setup for eap (peap & eap-fast has been tested > ok)
I have this error in the log:
12514 EAP-TLS failed SSL/TLS handshake because of an unknown CA in the client certificates chain
I think the Access Policies (identity & authorization) are misconfigured:
> I allowed Host Lookup, PAP/ASCII, MSCHAPV2, EAP-MD5, EAP-TLS, PEAP, EAP-FAST
> Identity: System:EAPauthentication match EAP-TLS
id Source: AD in which AD, Internal Users, Password based, certificate based CN Username are enabled
> authorization: System:WasMachineAuthenticated=True
Thanks for your help,
regards,

Hello,
I found the answer here:
https://supportforums.cisco.com/message/1298039#1298039
ACS self-signed certificate is not compatible with EAP-TLS
Thanks,

Client Certificate Authentication

Hi guys
I am not sure if this is the right place to ask but here I go. We are trying to find the best option to push client certificates to our user's Mobile Devices so they just log into a website, type their credentials and the user certificated get pushed.
We have implemented Workplace Join, this allows us to use the certificate pushed by ADFS to log into a webapp with the only once, then for some reason (still under investigation) doesn't work anymore.
I have also read about Client Certificate Mapping Authentication with IIS and AD but obviously the Client Certificate has to be in the mobile device in order to accomplish the authentication.
Windows Intune ultimately will do the trick but the idea of this research is to find out what's available in Microsoft platform.
any help would be truly appreciated
Jesus

If IIS is used for certificate distribution (and access to CRLs), I think this could be done with Active Directory Certificate Services.
Users could go to the website of the issuing certificate authorities and make a request.
I've only done this for real with Group Policy triggering the request behind the scenes for *domain members* and approval based on membership in a particular group.
So I'm not 100% sure how you would configure automatic issuance of the cert based on entry of a correct password. Usually, the "certificate managers" have to approve per company policy.
I'll look further though (interested in this myself).
Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

Certificate Authorities - JINIT 1.1.8.19

Similar Messages

Maybe you are looking for