X.509 registry - certificates

Hi,

I have a certificate that I received from here:

https://ssl.postescanada-canadapost.ca/tools/cst/web/CstStep1.aspx

I saved the certificate in a file and I am now trying to load the certificate into VW registry using:

| certificates registry |
registry := Security.X509.X509Registry new.
certificates := Security.X509.CertificateFileReader
readFromFile: 'ssl.postescanada-canadapost.ca.crt'.
certificates do: [ :certificate | registry addTrusted: certificate ].

And I get the following error message:

Basic Constraints are invalid for a CA certificate !

From my debugging, it seems that this is caused by basicConstraints isCritical being false.

This certificate works when installed in my browser, shouldn't it work "as is" when I attempt to install it in VW's registry?  Obviously I am missing something and any help would be appreciated.

Thanks,
Frank

Frank,

Assuming you'd saved it as Base-64 encoded X.509, the following does
work in clean 7.8 and 7.7.1 images with X509 loaded,

Security.X509.X509Registry readTrustedCertificatesFromFile:
'c:\canadapost.cer'.
Security.X509.X509Registry default trustedCertificates  ->  Set (X509v3:
ssl.postescanada-canadapost.ca <Entrust Certification Authority - L1C>
X509v3: ssl.postescanada-canadapost.ca <Entrust Certification Authority
- L1C>)

Also, you may actually want to just trust its root, or even something
like a common bundle,

http://leftshore.wordpress.com/2011/01/28/populating-x509registry/

Hope this helps,

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Flynch55
Sent: 29 May 2011 14:37
To: [hidden email]
Subject: [vwnc] X.509 registry - certificates

Hi,

I have a certificate that I received from here:

https://ssl.postescanada-canadapost.ca/tools/cst/web/CstStep1.aspx

I saved the certificate in a file and I am now trying to load the
certificate into VW registry using:

| certificates registry |
registry := Security.X509.X509Registry new.
certificates := Security.X509.CertificateFileReader
readFromFile: 'ssl.postescanada-canadapost.ca.crt'.
certificates do: [ :certificate | registry addTrusted: certificate ].

And I get the following error message:

Basic Constraints are invalid for a CA certificate !

>From my debugging, it seems that this is caused by basicConstraints
isCritical being false.

This certificate works when installed in my browser, shouldn't it work
"as is" when I attempt to install it in VW's registry?  Obviously I am
missing something and any help would be appreciated.

Thanks,
Frank


--
View this message in context:
http://forum.world.st/X-509-registry-certificates-tp3559302p3559302.html
Sent from the VisualWorks mailing list archive at Nabble.com.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

You're probably attempting to register the canadapost certificate. Instead you should register the top level CA certificate, in this case the one with CN = Entrust.net Certification Authority (2048) in the subject. The CA certificates are usually self-signed, i.e. the subject and issuer fields are identical. You should be able to export the certificate directly from your browser if you go to the "Manage Certificates" section of the Settings.

> This certificate works when installed in my browser, shouldn't it work "as
> is" when I attempt to install it in VW's registry?  Obviously I am missing
> something and any help would be appreciated.

I'm not sure what you mean by "installing in your browser". Generally you cannot install a third-party end-entity certificate in your browser. The reason it works is because the browser comes with a long list of CAs already pre-registered (including the one you need in this case, Entrust.net). Given a single CA certificate, you can verify any certificate issued by that one (generally thousands). That's the main point of the certificate hierarchies, you only need to know the roots of those hierarchies in order to verify thousands of end-entity certificates out there. You can see the full list of the CAs known to the browser in the "Manage Certificates" settings.

It's difficult to do something like that for a development platform like VW. Browser needs a long list of CAs because it is likely to be used to connect to a large number of servers. One would hope that the vendors verify their CA lists very carefully, but either way long list of CAs trades convenience for security. It only takes one compromised CA on that list and all security goes out the window. For general purpose dev. platform like VW, there really isn't a reasonable "one size fits all" list like that. Even if there was one, the due diligence required to maintain such CA list is beyond our capacity.

HTH,

Martin


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Martin,

As I mentioned in another message in this thread, we've had good success
using Mozilla's CA bundle to populate the registry in our applications
that regularly invoke HTTP(S) callbacks to arbitrary URLs as requested
by clients,

http://curl.haxx.se/docs/caextract.html
http://leftshore.wordpress.com/2011/01/28/populating-x509registry/

Of course, the above snippet isn't as intended to be used in live
deployments, you wouldn't want to rely on that URL being available all
the time. Instead, we have a scheduled task that fetches new bundles at
regular intervals and makes sure they hadn't suddenly regressed into
being complete duds.

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of [hidden email]
Sent: 31 May 2011 10:35
To: Flynch55
Cc: [hidden email]
Subject: Re: [vwnc] X.509 registry - certificates

You're probably attempting to register the canadapost certificate.
Instead you should register the top level CA certificate, in this case
the one with CN = Entrust.net Certification Authority (2048) in the
subject. The CA certificates are usually self-signed, i.e. the subject
and issuer fields are identical. You should be able to export the
certificate directly from your browser if you go to the "Manage
Certificates" section of the Settings.

> This certificate works when installed in my browser, shouldn't it work

> "as is" when I attempt to install it in VW's registry?  Obviously I am

> missing something and any help would be appreciated.

I'm not sure what you mean by "installing in your browser". Generally
you cannot install a third-party end-entity certificate in your browser.
The reason it works is because the browser comes with a long list of CAs
already pre-registered (including the one you need in this case,
Entrust.net). Given a single CA certificate, you can verify any
certificate issued by that one (generally thousands). That's the main
point of the certificate hierarchies, you only need to know the roots of
those hierarchies in order to verify thousands of end-entity
certificates out there. You can see the full list of the CAs known to
the browser in the "Manage Certificates" settings.

It's difficult to do something like that for a development platform like
VW. Browser needs a long list of CAs because it is likely to be used to
connect to a large number of servers. One would hope that the vendors
verify their CA lists very carefully, but either way long list of CAs
trades convenience for security. It only takes one compromised CA on
that list and all security goes out the window. For general purpose dev.
platform like VW, there really isn't a reasonable "one size fits all"
list like that. Even if there was one, the due diligence required to
maintain such CA list is beyond our capacity.

HTH,

Martin


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

"Boris Popov, DeepCove Labs"<[hidden email]> wrote:
Yup, I saw that, and that might be perfectly reasonable approach for your application (although personally, even if I decided to trust haxx.se to compile a CA bundle for me, I'd be antsy to fetch it over unprotected http). But that's your decision about your application, I don't think I can reasonably make the same kind of call for all (most) VW applications out there. Especially the ones that are connecting to only a handful of servers (most likely issued by single CA) should not be using long lists of CAs. I think the best we can do as VW vendor is explain and document various approaches of setting up and managing the trust registry.

Cheers,

Martin

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Martin,

Indeed, that's a perfectly reasonable approach for a vendor. In fact,
neither cURL nor OpenSSL supply their own CA bundles like they used to
and for exact same reasons. If anything, a section in the docs along the
lines of your detailed explanations might help most folks find their
answers.

Regards,

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: 31 May 2011 11:28
To: Boris Popov, DeepCove Labs
Cc: Flynch55; [hidden email]
Subject: RE: [vwnc] X.509 registry - certificates

"Boris Popov, DeepCove Labs"<[hidden email]> wrote:
> As I mentioned in another message in this thread, we've had good
> success using Mozilla's CA bundle to populate the registry in our
> applications that regularly invoke HTTP(S) callbacks to arbitrary URLs

> as requested by clients,
>
> http://curl.haxx.se/docs/caextract.html
> http://leftshore.wordpress.com/2011/01/28/populating-x509registry/
>
> Of course, the above snippet isn't as intended to be used in live
> deployments, you wouldn't want to rely on that URL being available all

> the time. Instead, we have a scheduled task that fetches new bundles
> at regular intervals and makes sure they hadn't suddenly regressed
> into being complete duds.

Yup, I saw that, and that might be perfectly reasonable approach for
your application (although personally, even if I decided to trust
haxx.se to compile a CA bundle for me, I'd be antsy to fetch it over
unprotected http). But that's your decision about your application, I
don't think I can reasonably make the same kind of call for all (most)
VW applications out there. Especially the ones that are connecting to
only a handful of servers (most likely issued by single CA) should not
be using long lists of CAs. I think the best we can do as VW vendor is
explain and document various approaches of setting up and managing the
trust registry.

Cheers,

Martin

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

"Boris Popov, DeepCove Labs"<[hidden email]> wrote:
> Indeed, that's a perfectly reasonable approach for a vendor. In fact,
> neither cURL nor OpenSSL supply their own CA bundles like they used to
> and for exact same reasons. If anything, a section in the docs along the
> lines of your detailed explanations might help most folks find their
> answers.

Starting with 7.7.1 we finally have a dedicated section on X.509 certificates in the SecurityGuide.pdf. Prior to that there was a discussion of the X509Registry buried in the SSL section (under Handshake and Certificates). While there's certainly room for further improvement, I'm glad there's finally at least something to point at :-).

Cheers,

Martin

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi Martin,

I registered the top level certificate "CN = Entrust.net Certification Authority (2048)" as you suggested
and when I inspect   Security.X509.X509Registry default trustedCertificates

I can see the certificate, it has the following data:
        Data:
                Version: 3 (0x2)
                Serial Number:
                        38:63:b9:66
                Signature Algorithm: sha-1WithRSAEncryption
                Issuer: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.),

This seems to indicate that I have correctly installed the certificate, is this assumption valid?

But when I run my app I get the following proceedable  exception:

Unhandled exception: Basic Constraints are required for a CA certificate !
Security.X509.X509Registry>>verifyBasicConstraints:
Security.X509.X509Registry>>verifyCACertificate:
optimized [] in [] in Security.X509.X509Registry>>validateCertificateChain:

My attempt at debugging shows the certificate it is trying to verify is:
Certificate:
        Data:
                Version: 3 (0x2)
                Serial Number:
                        38:63:b9:66
                Signature Algorithm: sha-1WithRSAEncryption
                Issuer: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net

I can proceed the exception and things work but I am wondering why is it complaining when it appears that I have installed the certificate and it is trusted.  And, how do I get rid of the exceptions.

Thanks,
Frank

Flynch55<[hidden email]> wrote:
This is the Issuer, what is the Subject ? Should be the same as Issuer.

Again, this is the Issuer, what is the Subject ? We may need to take a look at the whole chain (the argument of validateCertificateChain:), but this still suggests that the registry is not configured as it should be.

> I can proceed the exception and things work but I am wondering why is it
> complaining when it appears that I have installed the certificate and it is
> trusted.  And, how do I get rid of the exceptions.

Yes, if configured correctly there shouldn't be any warnings.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

> Again, this is the Issuer, what is the Subject ? We may need to take a look at the whole chain (the
> argument of validateCertificateChain:), but this still suggests that the registry is not configured as it
> should be.

The Issuer and the Subject were the same, the problem must have been with the registry.  I reinitialized the X509Registry and now it works like a charm.

Thank you Boris and Martin.

Cheers,
Frank