|
Home > Archive > BizTalk Server General > July 2005 > S/MIME Certificates from External CA
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
S/MIME Certificates from External CA
|
|
| Jeff Lynch 2005-07-13, 6:00 pm |
| Forgive my ignorance of digital certificates. So far I've always used
HTTPS/SSL server-side certificates but not (S/MIME - PKI) in BTS2004 running
on Win2K3.
I know that BizTalk Server 2004 can use a digital certificate for signing
and encryption (S/MIME) of outbound documents from a Windows Server acting
as a CA but can it use a certificate from an external CA such as VeriSign?
If so, how is the certificate "requested" from the external CA and what type
of certificate is required?
--
Jeff Lynch
"A BizTalk Enthusiast"
http://codebetter.com/blogs/jeff.lynch
| |
| lynn@garlic.com 2005-07-13, 8:52 pm |
| Jeff Lynch wrote:
> Forgive my ignorance of digital certificates. So far I've always used
> HTTPS/SSL server-side certificates but not (S/MIME - PKI) in BTS2004 running
> on Win2K3.
>
> I know that BizTalk Server 2004 can use a digital certificate for signing
> and encryption (S/MIME) of outbound documents from a Windows Server acting
> as a CA but can it use a certificate from an external CA such as VeriSign?
>
> If so, how is the certificate "requested" from the external CA and what type
> of certificate is required?
the technology is asymmetric cryptography ... what one key (of a
keypair) encodes, the other key (of the keypair) decodes. This is in
contrast to symmetric key cryptography where the same key is used to
both encode and decocde.
there is a business process called public key ... where one key (of a
keypair) is labeled public and is freely distributed. the other key (of
the keypair) is labeled private and is kept confidential and never
divulged.
there is a business process called digital signatures for doing
"something you have" authentication; basically the hash of a
message/document is computed and encode with the proviate key. the
message/document and the digital signature are transmitted. the
recipient recalculates the hash on the message/document and decodes the
digital signature with the public key and compares the two hashes. if
the two hashes are the same, then the recipient assumes
1) the message/document has not changed since being signed
2) "something you have" authentication; the originator has access and
use of the corresponding private key.
public keys can be registered in lieu of pins, passwords,
shared-secrets, etc as part of authentication protocols ... aka
http://www.garlic.com/~lynn/subpubkey.html#certless
http://www.garlic.com/~lynn/subpubkey.html#radius
http://www.garlic.com/~lynn/subpubkey.html#kerberos
PKIs, certification authorities, and digital certificates were created
to address the offline email type scenario from the early 80 (and
somewhat analogous to the "letters of credit" paradigm from the sailing
ship days). The recipient dials their local (electronic) post office,
exchanges email, and hangs up. at this point they may be faced with
first time communication from a total stranger and they have no local
&/or other means of establishing any information about the email
sender.
The infrastructure adds the public keys of trusted certification
authorities to the recipients repository of trusted public keys.
Individuals supply their public key and other information to a
certification authority and get back a digital certificate that
includes the public key, the supplied inoformation and digitally signed
by the certification authority. Now, when sending first time email to a
total stranger, the originator digitally signs the email and transmits
the 1) email, 2) the digital signature, and the 3) digital certificate.
The recipient validates the certification authorities digital signature
(on the digital certificate) using the corresponding public key from
their repository of trusted public keys. If the digital certificate
appears to be valid, then they validate the digital signature on the
mail using the public key from the digital certificate. They now can
interpret the email using what every useful certified information from
the digital certificate.
Basically, one might consider an "external certification authority" ...
as an authority that you haven't yet loaded their public key into your
repository of trusted public keys.
SSL/HTTPS domain name server certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert
were designed for
1) encrypted channel as countermeasure to evesdropping at any point in
the communication
2) is the webserver you are talking to really the webserver you think
you are talking to
Part of this was because of perceived integrity weaknesses in the
domain name infrastructure. A webserver address is typed into the
browser. the webserver sends back a digital certificate .... that has
been signed by a certification authority whos public key has been
preloaded into the browsers repository of trusted public keys. The
browser validates the digital signature on the digital certificate.
They then compare the domain name in the digital certificate with the
typed in domain name. Supposedly if they are the same ... you may be
talking to the webserver you think you are talking about
The browser now can generate a random session key and encode it with
the server's public key (from the digital certificate) and send it back
to the server. If this is the correct server, then the server will have
the corresponding private key and can decode the encrypted random
session key from the browser. From then on, the server and the browser
can exchange encrypted information using the random session key (if it
isn't the correct server, the server won't have access to the correct
private key and won't be able to decode the random session key sent by
the browser).
when this was originally be worked out
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
the objective was that the URL supplied by the end-user started out
using HTTPS. In the e-commerce world ... some number of servers found
that using HTTPS cut thruput by something like 80-90percent compared to
plain HTTP. So you started seeing ecommerce sites using simple HTTP for
all of the shopping experience and saving HTTPS when the user went to
hit the pay/checkout button. The problem is that if the user was at a
spoofed site during the HTTP portion ... than any fraudulent site would
likely supply a URL with the pay/checkout button that corresponded to a
URL in some valid digital certificate that they had (defeating the
objective of making sure the server you thot you were talking to was
actually the server you were talking to).
there is something of a catch-22 in this. A lot of certification
authorities are purely in the business of checking on the validity of
the information they are certifying ... they aren't actually the
authoritative agency for the actual information. In the SSL domain name
certificate scenario, the certification authorities ask from some
amount of identiification information from the certificate applicant.
They then contact the authoritative agency for domain name ownership
and cross-check the applicant's supplied identification information
with the identification information on file with the domain name
infrastructure as to the domain name ownership. Note however, this
domain name infrastructure which is the trust-root for things related
to domain names ... is the same domain name infrastructure which is
believe to have integrity issues that give rise to requirement for SSL
domain name certificates.
So a proposal, somewhat supported by the SSL domain name certification
authority industry ... is that domain name owners register their public
key with the domain name infrastructure. Then all future communication
with the domain name infrastructure is digitally signed ... which the
domain name infrastructure can validate with the on-file public key
(note: a certificateless operation). This communication validation is
thought to help eliminate some integrity issues.
For the certification authority industry, they now can also request
that SSL domain name certificate applications also be digital signed.
They now can change from an expensive, error-prone, and complex
identification process to a much simple and cheaper authentication
process (by retrieving the onfile public key from the domain name
infrastructure and validating the digital signature).
The catch22s are 1) improving the integrity of the trust-root for
domain name ownership also lowers the requirement for SSL domain name
certificates because of concerns about domain name infrastructure
integrity and 2) if the certification authority industry can retrieve
onfile public keys from the domain name infrastructure to validate who
they are communicating with ... it is possible that the rest of the
world could also ... eliminating any need for having SSL domain name
server certificates.
One could imagine a simplified and optimized SSL protocol, where the
client retrieves the ip-address and the associated public key from the
domain name infrastructure in a single, existing exchange. They could
then piggyback the randomly generated session key encoded with the
servers public key on the initial contact with the server.
Another issue was some trend in the early 90s to overload the x.509
identity certificates with large amounts of personal information ... in
hopes that future "strangers" (relying parties) would find something
useful when receiving first time communication.
In the mid-90s, there started to be some realization that x.509
identity certificates, grossly overloaded with personal information
represented significant privacy and liability issues. As a result, you
some institutions retrenching to relying-party-only certificates ...
basically a public key and some sort of database lookup index (where
all the real information about an individual was stored). However, it
was trivial to show that such relying-party-only certificates were
redundant and superfluous ... aka 1) they violated the premise of
supplying information for first-time communication between strangers
and 2) if the relying party (recipient) already had a superset of the
information found in a digital certificate (including the originator's
public key) ... then it was redundant and superfluous for the
originator get be constantly sending a copy of the certificate back to
the relying party on every communication.
The other issue was that there were attempts to try and have x.509
identity certificates attached to all digitally signed documents and
message. This basically resulted in causing a large amount of confusion
about the differences between authentication and identification ... and
would have effectively turned all electronic operations ... eeven the
most trivial authentication operations .... into heavyweight
identification operations.
| |
| Steven L Umbach 2005-07-13, 8:52 pm |
| Sure you can use a certificate/private key from an external CA. The
difference is all about "trust". In an enterprise where certificate usage
will be among your users and computer then often an internal CA is all you
need as you can manage what CA's that the computers/users will trust and can
be automated in an Active Directory forest. However when computer/users
outside of your enterprise will also access your computers/users using PKI
then certificates from an External CA may be best. For instance if you have
a web server that uses ssl with an internal CA certificate and users from
outside your enterprise try to access your web server via https they will
receive a warning message from their web browser that your website
certificate is not trusted which would then scare most sensible users away.
You can apply for a certificate at the major CA providers such as Verisign
for a fee. They have a free white paper that you can download and they will
help you get the proper certificate. See the links below if
terested. --- Steve
https://www.verisign.com/cgi-bin/cl...75.99.70&email=
http://www.verisign.com/verisign-bu...ions/index.html
http://www.mesagroup.com/html/digital_cert_get.html
"Jeff Lynch" <jeff.lynch@newsgroup.nospam> wrote in message
news:exy33U$hFHA.3936@TK2MSFTNGP10.phx.gbl...
> Forgive my ignorance of digital certificates. So far I've always used
> HTTPS/SSL server-side certificates but not (S/MIME - PKI) in BTS2004
> running on Win2K3.
>
> I know that BizTalk Server 2004 can use a digital certificate for signing
> and encryption (S/MIME) of outbound documents from a Windows Server acting
> as a CA but can it use a certificate from an external CA such as VeriSign?
>
> If so, how is the certificate "requested" from the external CA and what
> type of certificate is required?
>
> --
> Jeff Lynch
> "A BizTalk Enthusiast"
> http://codebetter.com/blogs/jeff.lynch
>
| |
| Steven L Umbach 2005-07-14, 2:48 am |
| Here is another link from Verisign for application for email
rtificate. -- Steve
http://www.verisign.com/products-se...l-id/index.html
"Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
news:eIUm0qBiFHA.1248@TK2MSFTNGP12.phx.gbl...
> Sure you can use a certificate/private key from an external CA. The
> difference is all about "trust". In an enterprise where certificate usage
> will be among your users and computer then often an internal CA is all you
> need as you can manage what CA's that the computers/users will trust and
> can be automated in an Active Directory forest. However when
> computer/users outside of your enterprise will also access your
> computers/users using PKI then certificates from an External CA may be
> best. For instance if you have a web server that uses ssl with an internal
> CA certificate and users from outside your enterprise try to access your
> web server via https they will receive a warning message from their web
> browser that your website certificate is not trusted which would then
> scare most sensible users away.
>
> You can apply for a certificate at the major CA providers such as Verisign
> for a fee. They have a free white paper that you can download and they
> will help you get the proper certificate. See the links below if
> rested. --- Steve
>
> https://www.verisign.com/cgi-bin/cl...75.99.70&email=
> http://www.verisign.com/verisign-bu...ions/index.html
> http://www.mesagroup.com/html/digital_cert_get.html
>
> "Jeff Lynch" <jeff.lynch@newsgroup.nospam> wrote in message
> news:exy33U$hFHA.3936@TK2MSFTNGP10.phx.gbl...
>
>
| |
| Jeff Lynch 2005-07-14, 5:51 pm |
| I'm still lost!
I believe I need a server digital ID for my BTS2004 machine rather than a
personal digital ID. I contacted Verisign and they weren't sure what
certificate I needed. If anyone has used an external CA for S/MIME (X.509?)
digital certificates please reply!
I've requested lots and lots of SSL Certificates from external CAs over the
years. Why is this so different?
If MS is listening (managed newsgroup, MSDN Universal subscriber), please
reply.
--
Jeff Lynch
"A BizTalk Enthusiast"
http://codebetter.com/blogs/jeff.lynch
"Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
news:OCirs1BiFHA.720@TK2MSFTNGP14.phx.gbl...
> Here is another link from Verisign for application for email
> ificate. -- Steve
>
> http://www.verisign.com/products-se...l-id/index.html
>
> "Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
> news:eIUm0qBiFHA.1248@TK2MSFTNGP12.phx.gbl...
>
>
| |
| Paul Adare 2005-07-14, 5:51 pm |
| In article <eNADqpKiFHA.1948@TK2MSFTNGP12.phx.gbl>, in the
microsoft.public.windows.server.security news group, Jeff Lynch
<jeff.lynch@newsgroup.nospam> says...
> I believe I need a server digital ID for my BTS2004 machine rather than a
> personal digital ID. I contacted Verisign and they weren't sure what
> certificate I needed. If anyone has used an external CA for S/MIME (X.509?)
> digital certificates please reply!
>
When it comes to S/MIME, there is no such thing as a personal versus
server digital ID. What you need is simply an S/MIME certificate. This
certificate is installed into the personal certificate store of the
service account that is used to run BizTalk. You can find details here:
http://msdn.microsoft.com/library/d...rl=/library/en-
us/introduction/htm/ebiz_plan_security_wlzd.asp
or
http://tinyurl.com/dkcb4
When requesting a certificate from a 3rd party CA you'd fill out their
form the same way as you would for a normal user who was going to use
the certificate for an email client, you'd just use the service account
information in the request.
--
Paul Adare
MVP - Windows - Virtual Machine
http://www.identit.ca/blogs/paul/
"The English language, complete with irony, satire, and sarcasm, has
survived for centuries without smileys. Only the new crop of modern
computer geeks finds it impossible to detect a joke that is not clearly
labeled as such."
Ray Shea
| |
| Jeff Lynch 2005-07-14, 5:51 pm |
| Thanks. I got one installed and working in BTS2004 just fine.
--
Jeff Lynch
"A BizTalk Enthusiast"
http://codebetter.com/blogs/jeff.lynch
"Paul Adare" <padare@newsguy.com> wrote in message
news:MPG.1d40920ccf2f72d5989ded@msnews.microsoft.com...
> In article <eNADqpKiFHA.1948@TK2MSFTNGP12.phx.gbl>, in the
> microsoft.public.windows.server.security news group, Jeff Lynch
> <jeff.lynch@newsgroup.nospam> says...
>
>
> When it comes to S/MIME, there is no such thing as a personal versus
> server digital ID. What you need is simply an S/MIME certificate. This
> certificate is installed into the personal certificate store of the
> service account that is used to run BizTalk. You can find details here:
>
> http://msdn.microsoft.com/library/d...rl=/library/en-
> us/introduction/htm/ebiz_plan_security_wlzd.asp
>
> or
>
> http://tinyurl.com/dkcb4
>
> When requesting a certificate from a 3rd party CA you'd fill out their
> form the same way as you would for a normal user who was going to use
> the certificate for an email client, you'd just use the service account
> information in the request.
>
> --
> Paul Adare
> MVP - Windows - Virtual Machine
> http://www.identit.ca/blogs/paul/
> "The English language, complete with irony, satire, and sarcasm, has
> survived for centuries without smileys. Only the new crop of modern
> computer geeks finds it impossible to detect a joke that is not clearly
> labeled as such."
> Ray Shea
|
|
|
|
|