1908Re: [soaplite] SOAP and SSL Client Certificates
- Oct 9, 2002On Wed, 2002-10-09 at 04:29, Simon.Fairey@... wrote:
> You mentioned it works with Class/Level 3 certificates? Sorry but I'mThere are actually different classes of certificates - they represent
> pretty new to SSL so that bit lost me.
different degrees of certainty as to the identity the certificate
certifies. In other words, a class one cert, i.e. an email certificate,
only requires that some be registered to receive mail at a given
address, but does not necessarily certify that just because I have a
cert signed to byrne@..., does not mean I work for IBM. A class 3
certificate on the other hand, typically a server certificate, is signed
to specific machine. A certificate authority then goes through a lengthy
process to ensure that the person requesting the cert, works for a valid
company, that the server belongs to the company, etc. I have a very high
level of confidence that if my app gets a level 3 cert signed by
verisign, that then person on the other end is the person represented by
the cert. Does that make sense?
As part of the SSL handshake, your SSL implementation will look at
fields the certificate in question (i.e. the Common Name, which often
holds the hostname as its value) and validate them. For level three
certs, the value of the CN is compared to the DNS name of the connected
client. If they match then the cert is accepted, otherwise, it is
Is this helping? Certificates in my experience are a pain. At Grand
Central we discovered the hard way that after paying several thousand
dollars for a server cert that we couldn't turn around and use the same
cert as a client cert. It makes tons of sense now, but it didn't at the
time. That is why we had to work with Verisign to come up with a new Web
Services cert that has an encoded dual purpose (yet another field
embedded in the cert like the CN).
A looooong answer, to a short question. Sorry. :/
> So HTTPS does work although there is little support, I notice in theOk - so that depends. If you are writing a service in SOAP::Lite to be
> building of SOAPLite it mentions HTTPS support so how do I implement a
> client/server where a client cert is used as authorisation. At the
> moment my perl client seems to work but completely ignores any sort of
> verification process?
consumed by others, I would let your web server handle all of the SSL
stuff for you (i.e. mod_ssl for Apache). If you are writing a client
that needs to consume a Web service over HTTPS, then I would just invoke
the service via HTTPS. As for client certificate based authentication...
let me get back to you. We solved this at GCC, but I have to dig through
some code. Let me ping an engineer who got this working and see if he
> Byrne Reese <breese@...>
> 07/10/2002 16:09
> To: simon.fairey@...
> cc: John Hartnup <john@...>, SOAP Lite Mailing
> List <email@example.com>
> Subject: Re: [soaplite] SOAP and SSL Client Certificates
> On Mon, 2002-10-07 at 09:55, simon.fairey@... wrote:
> > I have to then ask how people currently go about deploying secure soap
> > services. Guess I better go and trawl the web and newsgroups a bit :-)
> I don't think one can necessarily attribute the hesitency to use HTTPS
> to secure web services to the lack of support in WSDL. WSDL describes an
> interface - not the transport mechanism to use.
> SAML is good to encrypt data within a SOAP envelope. In other words, if
> you want to protect just some of the data allowing others to still parse
> the XML (i.e. an intermediary) - than SAML seems like a good fit.
> WS-Security comes into play for authentication, and identity
> confirmation... SAML and WS-S have a lot in common, but there are
> certainly some differentiators between them.
> Right now, in my experience at Grand Central where we *only* deploy
> secure Web services is that HTTPS is the only way to go - only because
> it has such wide spread support. It is not the best solution to the
> problem, but it does provide encryption, and some level identity
> confirmation/authentication (when using Class/Level 3 certificates).
> Toolkit support is good for HTTPS, and your web server should make HTTPS
> completely transparent to SOAP::Lite.
> Verisign provides a very useful certificate that Grand Central helped to
> justify the need for: a dual purpose client and server cert. This
> enables you to use the same cert for processing requests as you do for
> sending requests. Very helpful, and it is what we use exclusively.
> IMHO, HTTPS is your best bet for right now. If you will be involving
> lots of intermediaries, take a look at Grand Central - only because it
> can help you to manage your security policies across multiple end
> BTW - If you think support for HTTPS is weak. Try finding good tools for
> SAML, and WS-S. They are virtually non-existent.
> > Thanks for the reply.
> > Si
> > John Hartnup <john@...>
> > 07/10/2002 14:52
> > Please respond to John Hartnup
> > To: simon.fairey@...
> > cc: firstname.lastname@example.org
> > Subject: Re: [soaplite] SOAP and SSL Client
> > On Mon, Oct 07, 2002 at 04:12:33PM +0000, simon.fairey@... wrote:
> > > Hi,
> > >
> > > I'm going to be providing some simple functions to a client via an
> > Apache
> > > mod_soap setup. There is also a requirement to use client side
> > > certificates. Now I think I have my server set up correctly and when
> > try
> > > to acces (using SOAP::Lite) a simple hello msg via https it seems to
> > work
> > > fine with no demands for a client side certificate?
> > >
> > > Assuming my apache is set up properly then my question would be how
> > you
> > > tell your SOAP client perl script what certificate to use when
> > accessing
> > > an SSL enabled service?
> > >
> > > I'm assuming I'm not barking up the wrong tree, I have the
> > Web
> > > Services with SOAP book and am working through it but have yet to
> > > much info on SOAP and SSL. Should I be using something like SAML,
> > briefly
> > > skimmed it in the book and now think I might go back and read it in
> > more
> > > detail!!
> > My undersanding (and I look forward to being corrected on this) is
> > in
> > general SOAP client toolkits do not cater for HTTPS client
> > authentication.
> > One reason might be that WSDL doesn't provide a mechanism (to my
> > knowledge) to descibe a service which requires authentication.
> > Another reason is that the community hasn't decided yet whether HTTPS
> > the
> > right way to go about SOAP security. After all, the lifecycle of a
> > message
> > isn't limited to a single hop, but SSL only protects the first hope
> > HTTPS
> > client to HTTPS server.
> > It looks as if WS-Security, or one of its competitors, where the SOAP
> > body
> > consists of an encrypted element, and the SOAP header contains
> > elements (certificates, tokens, signatures etc.) might be the way
> > security gets
> > done in the future, but at the moment there is no widely accepted way
> > do it,
> > and certainly none that is widely implemented in a toolkit.
> > You'll have to accept that whatever you implement today will probably
> > never be
> > "standard", and that if that's important to you, you'll need to
> > re-implement to
> > comply with whatever standard emerges, whenever that happens.
> > OTOH, someone please tell me I'm wrong, because I have a service I'd
> > love
> > to deploy, which requires strong security.
> > --
> > "Feel free to browse, but try not to carouse. Hoho"
> > This email may contain confidential material. If you were not an
> > intended recipient, please notify the sender and delete all copies.
> > We may monitor email to and from our network.
> > To unsubscribe from this group, send an email to:
> > email@example.com
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
> > <http://docs.yahoo.com/info/terms/> .
> :/ byrne
> Program Manager
> Grand Central Communications
> This email may contain confidential material. If you were not an
> intended recipient, please notify the sender and delete all copies.
> We may monitor email to and from our network.
Grand Central Communications
- << Previous post in topic Next post in topic >>