Redirect stops links from here
http://www.openssl.org/related/
http://www.openssl.org/docs/apps/openssl.html
Toolkits
These are references to various toolkits and libraries which implement the SSL/TLS protocols and related standards like the X.509 certificate system.OpenSSL http://www.openssl.org/The open-source toolkit for SSL/TLSRSA BSAFE SSL-C http://www.aus.rsa.com/products/sslc/The commercial successor toolkit to SSLeay from RSA DSISSLPlus http://www.consensus.com/sslplus/Another commercial toolkit for SSL/TLS from Certicom/ConsensusSpyrus TLS Gold Toolkit http://www.spyrus.com/content/products/ssl/tlsgold/Another commercial toolkit for SSL/TLS from SpyrusSSLRef ftp://ftp.replay.com/pub/crypto/SSL/Netscape's old SSL reference library from Netscape/Consensus (no longer available)Oscar http://oscar.dstc.qut.edu.au/A public key certification system's toolkitLSM-PKCS11 http://www.clizio.com/lsmpkcs11.htmlA security module accessible as a PKCS#11 library
$ openssl s_client -connect <host>:<port> > foo.cert
Again, lately I've been working on a project that requires the use of SSL and therefore certificates. This is just a note for my own posterity more than anything, but if you ever need to grab a SSL certificate from a host so that you can import it into your keystore, here's how to do so using the OpenSSL s_client:$ openssl s_client -connect <host>:<port> > foo.cert Just make sure to substitute the <host> with the DNS name of the host and the <port> with the actual port number. Once you have the foo.cert file, you will need to manually clean up the foo.cert file a little bit, but it works. Here's a quick example: $ openssl s_client -connect <host>:<port> > foo.cert
http://bsnyderblog.blogspot.com/2013/01/how-to-list-all-certificates-in-jdk.html?m=1
How To List All Certificates in the JDK cacerts File
Lately I've been working on a project that requires the use of SSL and therefore certificates. While working though the necessary tasks, I became curious about the number of certificates that exist in the default truststore in the JDK for Mac OS X (it's named cacerts). Well using Java's keytool utility it's easy to take a peek at them. Here's how to list them:$ echo 'changeit' | keytool -list -v -keystore $(find $JAVA_HOME -name cacerts) | grep 'Owner:' Enter keystore password: Owner: CN=TWCA Root Certification Authority, OU=Root CA, O=TAIWAN-CA, C=TW Owner: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US Owner: CN=NetLock Uzleti (Class B) Tanusitvanykiado, OU=Tanusitvanykiadok, O=NetLock Halozatbiztonsagi Kft., L=Budapest, C=HU Owner: CN=Certum Trusted Network CA, OU=Certum Certification Authority, O=Unizeto Technologies S.A., C=PL Owner: CN=Wells Fargo Root Certificate Authority, OU=Wells Fargo Certification Authority, O=Wells Fargo, C=US Owner: CN=Chambers of Commerce Root, OU=http://www.chambersign.org, O=AC Camerfirma SA CIF A82743287, C=EU Owner: CN=Global Chambersign Root, OU=http://www.chambersign.org, O=AC Camerfirma SA CIF A82743287, C=EU Owner: OU=RSA Security 2048 V3, O=RSA Security Inc ... This results in a tremendous amount of output hence the grep to list just the owner. According to this method of listing the certs in the default truststore, there are 183. I just glanced through the list and they seem to come from CAs all over the world. I wonder how it was determined which certs to place in the default truststore?Bruce Snyder at 9:16 AM
No comments:
How To List All Certificates in the JDK cacerts File
Lately I've been working on a project that requires the use of SSL and therefore certificates. While working though the necessary tasks, I became curious about the number of certificates that exist in the default truststore in the JDK for Mac OS X (it's named cacerts). Well using Java's keytool utility it's easy to take a peek at them. Here's how to list them:$ echo 'changeit' | keytool -list -v -keystore $(find $JAVA_HOME -name cacerts) | grep 'Owner:' Enter keystore password: Owner: CN=TWCA Root Certification Authority, OU=Root CA, O=TAIWAN-CA, C=TW Owner: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US Owner: CN=NetLock Uzleti (Class B) Tanusitvanykiado, OU=Tanusitvanykiadok, O=NetLock Halozatbiztonsagi Kft., L=Budapest, C=HU Owner: CN=Certum Trusted Network CA, OU=Certum Certification Authority, O=Unizeto Technologies S.A., C=PL Owner: CN=Wells Fargo Root Certificate Authority, OU=Wells Fargo Certification Authority, O=Wells Fargo, C=US Owner: CN=Chambers of Commerce Root, OU=http://www.chambersign.org, O=AC Camerfirma SA CIF A82743287, C=EU Owner: CN=Global Chambersign Root, OU=http://www.chambersign.org, O=AC Camerfirma SA CIF A82743287, C=EU Owner: OU=RSA Security 2048 V3, O=RSA Security Inc ... This results in a tremendous amount of output hence the grep to list just the owner. According to this method of listing the certs in the default truststore, there are 183. I just glanced through the list and they seem to come from CAs all over the world. I wonder how it was determined which certs to place in the default truststore?Bruce Snyder at 9:16 AM
No comments:
How To List All Certificates in the JDK cacerts File
Lately I've been working on a project that requires the use of SSL and therefore certificates. While working though the necessary tasks, I became curious about the number of certificates that exist in the default truststore in the JDK for Mac OS X (it's named cacerts). Well using Java's keytool utility it's easy to take a peek at them. Here's how to list them:$ echo 'changeit' | keytool -list -v -keystore $(find $JAVA_HOME -name cacerts) | grep 'Owner:' Enter keystore password: Owner: CN=TWCA Root Certification Authority, OU=Root CA, O=TAIWAN-CA, C=TW Owner: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US Owner: CN=NetLock Uzleti (Class B) Tanusitvanykiado, OU=Tanusitvanykiadok, O=NetLock Halozatbiztonsagi Kft., L=Budapest, C=HU Owner: CN=Certum Trusted Network CA, OU=Certum Certification Authority, O=Unizeto Technologies S.A., C=PL Owner: CN=Wells Fargo Root Certificate Authority, OU=Wells Fargo Certification Authority, O=Wells Fargo, C=US Owner: CN=Chambers of Commerce Root, OU=http://www.chambersign.org, O=AC Camerfirma SA CIF A82743287, C=EU Owner: CN=Global Chambersign Root, OU=http://www.chambersign.org, O=AC Camerfirma SA CIF A82743287, C=EU Owner: OU=RSA Security 2048 V3, O=RSA Security Inc ... This results in a tremendous amount of output hence the grep to list just the owner. According to this method of listing the certs in the default truststore, there are 183. I just glanced through the list and they seem to come from CAs all over the world. I wonder how it was determined which certs to place in the default truststore?Bruce Snyder at 9:16 AM
No comments:
How To List All Certificates in the JDK cacerts File
Lately I've been working on a project that requires the use of SSL and therefore certificates. While working though the necessary tasks, I became curious about the number of certificates that exist in the default truststore in the JDK for Mac OS X (it's named cacerts). Well using Java's keytool utility it's easy to take a peek at them. Here's how to list them:$ echo 'changeit' | keytool -list -v -keystore $(find $JAVA_HOME -name cacerts) | grep 'Owner:' Enter keystore password: Owner: CN=TWCA Root Certification Authority, OU=Root CA, O=TAIWAN-CA, C=TW Owner: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US Owner: CN=NetLock Uzleti (Class B) Tanusitvanykiado, OU=Tanusitvanykiadok, O=NetLock Halozatbiztonsagi Kft., L=Budapest, C=HU Owner: CN=Certum Trusted Network CA, OU=Certum Certification Authority, O=Unizeto Technologies S.A., C=PL Owner: CN=Wells Fargo Root Certificate Authority, OU=Wells Fargo Certification Authority, O=Wells Fargo, C=US Owner: CN=Chambers of Commerce Root, OU=http://www.chambersign.org, O=AC Camerfirma SA CIF A82743287, C=EU Owner: CN=Global Chambersign Root, OU=http://www.chambersign.org, O=AC Camerfirma SA CIF A82743287, C=EU Owner: OU=RSA Security 2048 V3, O=RSA Security Inc ... This results in a tremendous amount of output hence the grep to list just the owner. According to this method of listing the certs in the default truststore, there are 183. I just glanced through the list and they seem to come from CAs all over the world. I wonder how it was determined which certs to place in the default truststore?Bruce Snyder at 9:16 AM
No comments:
removed from NSS.OU = RSA Security 1024 V3O = RSA Security IncValid From: 2/22/01Valid To: 2/22/26SHA1 Fingerprint: 3C:BB:5D:E0:FC:D6:39:7C:05:88:E5:66:97:BD:46:2A:BD:F9:5C:76I have not been able to find the current owner of this root. Both RSA and VeriSign have stated in email that they do not own this root.Therefore, to my knowledge this root has no current owner and no current audit, and should be removed from NSS.I have also filed a bug for this:https://bugzilla.mozilla.org/show_bug.cgi?id=549701I am now opening this proposal up to public discussion. Please respond to this discussion if you have any knowledge of this root that would help in making this decision.By the way, To see the complete list of all of the root certificate authorities that are included in NSS, and who currently owns/operates them, go to http://www.mozilla.org/projects/security/certs/ and click on the "List of all included root certificates" link. This will display the public and published version of a spreadsheet that I maintain. There is a column called "Company Website" which indicates the current owner of each root.KathleenReply4/2/10Gen KanaiOn 4/3/10 2:19 AM, Kathleen Wilson wrote:> I have not been able to find the current owner of this root. Both RSA > and VeriSign have stated in email that they do not own this root.>> Therefore, to my knowledge this root has no current owner and no current > audit, and should be removed from NSS.> I concur.Separately, do we know how a root with such a name (if RSA was not the owner) was installed?-- Gen KanaiReply4/3/10Nelson BolyardOn 2010-04-02 10:19 PST, Kathleen Wilson wrote:> All,> > I propose that the "RSA Security 1024 V3" root certificate authority be > removed from NSS.> > OU = RSA Security 1024 V3> O = RSA Security Inc> Valid From: 2/22/01> Valid To: 2/22/26> SHA1 Fingerprint: > 3C:BB:5D:E0:FC:D6:39:7C:05:88:E5:66:97:BD:46:2A:BD:F9:5C:76> > I have not been able to find the current owner of this root. Both RSA > and VeriSign have stated in email that they do not own this root.> > Therefore, to my knowledge this root has no current owner and no current > audit, and should be removed from NSS.Who owns the cert named "RSA Security 2048 V3"?It was put into nssckbi at the same time as the 1024 v3 cert.Is that one also owned by nobody?If so, let's nuke 'em both together.Reply4/3/10Nelson Bolyard- show quoted text -See bugzilla bug 139874Reply4/3/10Florian Weimer* Gen Kanai:> Separately, do we know how a root with such a name (if RSA was not> the owner) was installed?They do not own it now, but the company likely created it.For instance, the Equifax root isn't controlled by Equifax anymore,and there a couple of such examples. There was a time when roots weretraded heavily.Reply4/5/10Gervase MarkhamOn 02/04/10 18:19, Kathleen Wilson wrote:> I have not been able to find the current owner of this root. Both RSA> and VeriSign have stated in email that they do not own this root.That's rather worrying. Do we know for certain that one or other created it originally? Do we know if it's in any other root stores other than our own?The lack of transparency in 2002 re: the source of added roots means we have no idea whether e.g. some malicious actor slipped an extra one into whatever list they were keeping internally to Netscape, and has been MITMing people ever since.GervReply4/5/10Kathleen WilsonOn 4/5/10 11:28 AM, Gervase Markham wrote:> On 02/04/10 18:19, Kathleen Wilson wrote:>> I have not been able to find the current owner of this root. Both RSA>> and VeriSign have stated in email that they do not own this root.>> That's rather worrying. Do we know for certain that one or other created> it originally?Both "RSA Security 1024 V3" and "RSA Security 2048 V3" have the same validity dates of 2001 Feb 22 to 2026 Feb 22. I believe that both of these roots were created by RSA. I have not been able to ascertain from RSA whether the "RSA Security 1024 V3" root has been simply retired by RSA versus transferred to another company via M&A activity.The "RSA Security 2048 V3" root is covered under RSA's current audit statement: https://cert.webtrust.org/SealFile?seal=981&file=pdf> Do we know if it's in any other root stores other than> our own?Both "RSA Security 1024 V3" and "RSA Security 2048 V3" are shown as valid in Apple's System Roots.Microsoft's list includes "RSA Security 2048 V3", but not "RSA Security 1024 V3".KathleenReply4/5/10wwa...@gmx.deOn Apr 5, 2:53 pm, Kathleen Wilson <kathleen95...@yahoo.com> wrote:> Both "RSA Security 1024 V3" and "RSA Security 2048 V3" have the same> validity dates of 2001 Feb 22 to 2026 Feb 22. I believe that both of> these roots were created by RSA.The same validity range is not a proof of any kind. It should reallybechecked if this CA was created by RSA or - which i do hope not - isa rogue one by someone who just set the same date range in hiscertificate and then somehow got it included.This could be a utter security desaster. Lets hope it isn't.Reply4/6/10Gervase MarkhamOn 05/04/10 19:53, Kathleen Wilson wrote:> Both "RSA Security 1024 V3" and "RSA Security 2048 V3" have the same> validity dates of 2001 Feb 22 to 2026 Feb 22. I believe that both of> these roots were created by RSA.Do you believe that based solely on the validity dates?If I had access to the machine of a Netscape NSS developer who was about to update the root store, and I wanted to slip in a cert I had the private key for, I'd add another entry to the store which was very similar to an existing one but with one obvious difference, so that people would assume they were a set.Perhaps this is far-fetched and paranoid. But the fact that RSA know nothing whatsoever about this root is rather concerning.> Both "RSA Security 1024 V3" and "RSA Security 2048 V3" are shown as> valid in Apple's System Roots.Hmm. Do we have contacts at Apple who we can ask to see if they have documentation on the provenance of this root?GervReply4/6/10RonnyGoogle accepts "RSA Security 1024 V3" and "RSA Security 2048 V3" fortheir Checkout API authentication too.see http://checkout.google.com/support/sell/bin/answer.py?hl=en&answer=57856According to bonsai, the certificate was installed in version 1.17(http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/security/nss/lib/ckfw/builtins&command=DIFF_FRAMESET&file=certdata.txt&rev1=1.16&rev2=1.17&root=/cvsroot) by Julien Pierre as part of bug #139874 (https://bugzilla.mozilla.org/show_bug.cgi?id=139874).Reply4/6/10vortexOn Apr 6, 1:14 pm, Ronny <ronny.peri...@gmail.com> wrote:> Google accepts "RSA Security 1024 V3" and "RSA Security 2048 V3" for> their Checkout API authentication too.>> seehttp://checkout.google.com/support/sell/bin/answer.py?hl=en&answer=57856>> According to bonsai, the certificate was installed in version 1.17> (http://bonsai.mozilla.org/cvsview2.cgi?> diff_mode=context&whitespace_mode=show&subdir=mozilla/security/nss/lib/> ckfw/> builtins&command=DIFF_FRAMESET&file=certdata.txt&rev1=1.16&rev2=1.17&root=/> cvsroot) by Julien Pierre as part of bug #139874 (https://> bugzilla.mozilla.org/show_bug.cgi?id=139874).Did anyone check with Valicert? Apparently this very issue came up in2006 in Debian world.http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/5b33fa29d3d83c66/5a6fe5ca3e2da747?hl=en&ie=UTF-8&q=%22RSA+Security+1024+V3%22#5a6fe5ca3e2da747Reply4/6/10wwa...@gmx.deOn Apr 6, 8:34 pm, vortex <rafael.riv...@gmail.com> wrote:> Did anyone check with Valicert? Apparently this very issue came up in> 2006 in Debian world.http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/t...You should better reread that message. Valicert has nothing to do withthis. The "RSA Security 1024 V3" CA was only shown as an example of aCA by RSA in that
https://groups.google.com/forum/m/?fromgroups#!topic/mozilla.dev.security.policy/tkk6KFunmZg
No comments:
Post a Comment