Digital certificate management v1 (Draft)

Digital Certificate Management: Public Key Infrastructure
Training Material
Copyright. Infinity Solution Service Co., Ltd. 2011-2015
Author: Avirot Mitamura L. / Senior Security Consultant
1
Digital Certificate Management

Course Outline
Course Title: Digital Certificate Management
Course Period: 2 Days
Objective: Understanding of PKI Concept
Acquire Knowledge of Digital Certificate
Acquire Knowledge of PKI Functions
Manageable of Key and Functions
Pre-requisite: Server Administration
Basic Networking (TCP/IP)
Fundamental Mathematic Algorithm
Basic Information Security Concept (CIA)
2

3

Course: Digital Certificate Management – Public Key Infrastructure
Day 1 : Agenda
Chapter 1: Introduction to PKI
Chapter 2: Algorithm, Standard, Protocol
Chapter 3: Digital Certificate
Chapter 4: Cryptography Service Provider
Chapter 5: Web Certificate Management
4

Public Key Infrastructure (PKI) is a set of hardware, software, people, policies, and
procedures needed to create, manage, distribute, use, store, and revoke digital
certificates.
In cryptography, a PKI is an arrangement that binds public keys with respective user
identities by means of a certificate authority (CA). The user identity must be unique
within each CA domain. The third-party validation authority (VA) can provide this
information on behalf of CA. The binding is established through the registration and
issuance process, which, depending on the assurance level of the binding, may be
carried out by software at a CA or under human supervision. The PKI role that assures
this binding is called the registration authority (RA), which ensures that the public key is
bound to the individual to which it is assigned in a way that ensures non-repudiation.
AuthenticationAllows your e-business to engage
trusted customers, partners and employees.
ConfidentialityData is obscured and protected from
view or access by unauthorized individuals.
Entitlement Allows business rules to dictate who uses
(Access Control) what resources, under what conditions.
5

Integrity Prevents any transaction from being tampered with
Non-repudiation Prevents any party from denying an e-business
transaction after the fact.
Audit controls Provides audit trails and recourse for e-business
transactions
Public key cryptography is a cryptographic technique that enables users to securely
communicate on an insecure public network, and reliably verify the identity of a user via
digital signatures which require:
• Hashing Algorithm
• Asymmetric Algorithm (Public Key Algorithm)
• Symmetric Algorithm (Shared Key Algorithm)
5

PKI Key Components:
Public key cryptography is a cryptographic technique that enables users to securely
communicate on an insecure public network, and reliably verify the identity of a user via
digital signatures.
A public key infrastructure (PKI) is a system for the creation, storage, and distribution of
digital certificates which are used to verify that a particular public key belongs to a
certain entity. The PKI creates digital certificates which map public keys to entities,
securely stores these certificates in a central repository and revokes them if needed.
A PKI consists of:
• A certificate authority (CA) that both issues and verifies the digital certificates
• A registration authority which verifies the identity of users requesting information
from the CA
• A central directory—i.e., a secure location in which to store and index keys
• A certificate management system
• A certificate policy
6

Certificate Authority (CA)
Certificate Authority is an entity that issues digital certificates. A digital certificate
certifies the ownership of a public key by the named subject of the certificate. This
allows others (relying parties) to rely upon signatures or on assertions made by the
private key that corresponds to the certified public key. In this model of trust
relationships, a CA is a trusted third party - trusted both by the subject (owner) of the
certificate and by the party relying upon the certificate.
Trusted certificates are typically used to make secure connections to a server over the
Internet. A certificate is required in order to avoid the case that a malicious party which
happens to be on the path to the target server pretends to be the target. Such a
scenario is commonly referred to as a man-in-the-middle attack. The client uses the CA
certificate to verify the CA signature on the server certificate, as part of the checks
before establishing a secure connection. Usually, client software—for example,
browsers—include a set of trusted CA certificates. That makes sense in as much as users
need to trust their client software: A malicious or compromised client can skip any
security check and still fool its users into believing otherwise.
The customers of a CA are server administrators who need a certificate that their servers
will present to clients. Commercial CAs charge to issue certificates, and their customers
expect the CA's certificate to be included by most web browsers, so that secure
connections to the certified server work smoothly out of the box. The number of web
browsers and other devices and applications that trust a particular certificate authority
7

is referred to as ubiquity. Mozilla, which is a non-profit organization, distributes several
commercial CA certificates with its products.[1]While Mozilla developed their own policy,
the CA/Browser Forum developed similar guidelines for CA trust. A single CA certificate
may be shared among multiple CAs or their resellers. A root CA certificate may be the
base to issue multiple intermediate CA certificates with varying validation requirements.
7

Trusted Third Party (TTP) Principle is an entity which facilitates interactions between two
parties who both trust the third party; The Third Party reviews all critical transaction
communications between the parties, based on the ease of creating fraudulent digital
content. In TTP models, the relying parties use this trust to secure their own
interactions. TTPs are common in any number of commercial transactions and in
cryptographic digital transactions as well as cryptographic protocols, for example, a
certificate authority (CA) would issue a digital identity certificate to one of the two
parties in the next example. The CA then becomes the Trusted-Third-Party to that
certificates issuance. Likewise transactions that need a third party recordation would
also need a third-party repository service of some kind or another.
How to arrange for (trustable) third parties of this type is an unsolved problem. So long
as there are motives of greed, politics, revenge, etc., those who perform (or supervise)
work done by such an entity will provide potential loopholes through which the
necessary trust may leak. The problem, perhaps an unsolvable one, is ancient and
notorious. That large impersonal corporations make promises of accuracy in their
attestations of the correctness of a claimed public-key-to-user correspondence (e.g., by
a certificate authority as a part of a public key infrastructure) changes little. As in many
environments, the strength of trust is as weak as its weakest link. When the
infrastructure of a trusted CA is breached the whole chain of trust is broken. The 2011
incident at CA DigiNotar broke the trust of the Dutch governments PKI, and is a text-book
example of the weaknesses of the system and the effects of it. As Bruce Schneier
has pointed out, after the 2013 mass surveillance disclosures, no third party should in
fact ever be trusted.
8

The PGP cryptosystem includes a variant of the TTP in the form of the web of trust. PGP
users digitally sign each other's identity certificates and are instructed to do so only if
they are confident the person and the public key belong together. A key signing party is
one way of combining a get-together with some certificate signing. Nonetheless, doubt
and caution remain sensible as some users have been careless in signing others'
certificates.
Trusting humans, or their organizational creations, can be risky. For example, in financial
matters, bonding companies have yet to find a way to avoid losses in the real world.
8

PKI: e-Business Enabler
• Makes trusted e-business possible
• Enables new e-business processes
• Provides integrated, comprehensive:
Encryption
- Authorization
- Confidentiality
Digital Signature
- Authentication
- Integrity
- Non-repudiation
- Audit controls
Note: ...Transparently to users across applications and platforms for Enterprise PKI
Solution.
9

SYMMETRIC KEY ALGORITHM
Symmetric-key algorithms are a class of algorithms for cryptography that use the same
cryptographic keys for both encryption of plaintext and decryption of ciphertext. The
keys may be identical or there may be a simple transformation to go between the two
keys. The keys, in practice, represent a shared secret between two or more parties that
can be used to maintain a private information link. This requirement that both parties
have access to the secret key is one of the main drawbacks of symmetric key encryption,
in comparison to public-key encryption.
Symmetric-key encryption can use either stream ciphers or block ciphers.
Stream ciphers encrypt the digits (typically bytes) of a message one at a time.
Block ciphers take a number of bits and encrypt them as a single unit, padding the
plaintext so that it is a multiple of the block size. Blocks of 64 bits have been commonly
used. The Advanced Encryption Standard (AES) algorithm approved by NIST in December
2001 uses 128-bit blocks.
10

ASYMMETRIC KEY ALGORITHM
Public-key cryptography, also known as asymmetric cryptography, is a class of
cryptographic algorithms which requires two separate keys, one of which is secret (or
private) and one of which is public. Although different, the two parts of this key pair are
mathematically linked. The public key is used to encrypt plaintext or to verify a digital
signature; whereas the private key is used to decrypt ciphertext or to create a digital
signature. The term "asymmetric" stems from the use of different keys to perform these
opposite functions, each the inverse of the other – as contrasted with conventional
("symmetric") cryptography which relies on the same key to perform both.
Public-key algorithms are based on mathematical problems which currently admit no
efficient solution that are inherent in certain integer factorization, discrete logarithm,
and elliptic curve relationships. It is computationally easy for a user to generate their
own public and private key-pair and to use them for encryption and decryption. The
strength lies in the fact that it is "impossible" (computationally infeasible) for a properly
generated private key to be determined from its corresponding public key. Thus the
public key may be published without compromising security, whereas the private key
must not be revealed to anyone not authorized to read messages or perform digital
signatures. Public key algorithms, unlike symmetric key algorithms, do not require a
secure initial exchange of one (or more) secret keys between the parties.
Message authentication involves processing a message with a private key to produce a
digital signature. Thereafter anyone can verify this signature by processing the signature
value with the signer's corresponding public key and comparing that result with the
11

message. Success confirms the message is unmodified since it was signed, and –
presuming the signer's private key has remained secret to the signer – that the signer,
and no one else, intentionally performed the signature operation. In practice, typically
only a hash or digest of the message, and not the message itself, is encrypted as the
signature.
Public-key algorithms are fundamental security ingredients in cryptosystems, applications
and protocols. They underpin various Internet standards, such as Transport Layer Security
(TLS), PGP, and GPG. Some public key algorithms provide key distribution and secrecy
(e.g., Diffie–Hellman key exchange), some provide digital signatures (e.g., Digital
Signature Algorithm), and some provide both (e.g., RSA).
Public-key cryptography finds application in, amongst others, the IT security discipline
information security. Information security (IS) is concerned with all aspects of protecting
electronic information assets against security threats.[1] Public-key cryptography is used
as a method of assuring the confidentiality, authenticity and non-reputability of
electronic communications and data storage.
There are two main uses for public-key cryptography:
Public-key encryption, in which a message is encrypted with a recipient's public key. The
message cannot be decrypted by anyone who does not possess the matching private key,
who is thus presumed to be the owner of that key and the person associated with the
public key. This is used in an attempt to ensure confidentiality.
Digital signatures, in which a message is signed with the sender's private key and can be
verified by anyone who has access to the sender's public key. This verification proves that
the sender had access to the private key, and therefore is likely to be the person
associated with the public key. This also ensures that the message has not been
tampered with, as any manipulation of the message will result in changes to the encoded
message digest, which otherwise remains unchanged between the sender and receiver.
An analogy to public-key encryption is that of a locked mail box with a mail slot. The mail
slot is exposed and accessible to the public – its location (the street address) is, in
essence, the public key. Anyone knowing the street address can go to the door and drop a
written message through the slot. However, only the person who possesses the key can
open the mailbox and read the message.
An analogy for digital signatures is the sealing of an envelope with a personal wax seal.
The message can be opened by anyone, but the presence of the unique seal
authenticates the sender.
A central problem with the use of public-key cryptography is confidence/proof that a
particular public key is authentic, in that it is correct and belongs to the person or entity
claimed, and has not been tampered with or replaced by a malicious third party. The
usual approach to this problem is to use a public-key infrastructure (PKI), in which one or
more third parties – known as certificate authorities – certify ownership of key pairs. PGP,
in addition to being a certificate authority structure, has used a scheme generally called
the "web of trust", which decentralizes such authentication of public keys by a central
mechanism, and substitutes individual endorsements of the link between user and public
key. To date, no fully satisfactory solution to the "public key authentication problem" has
been found.
11

Common Algorithms
• Diffie–Hellman key exchange protocol
• DSS (Digital Signature Standard), which incorporates the Digital Signature Algorithm
• ElGamal
• Various elliptic curve techniques
• Various password-authenticated key agreement techniques
• Paillier cryptosystem
• RSA encryption algorithm (PKCS#1)
• Cramer–Shoup cryptosystem
• YAK authenticated key agreement protocol
11

HASHING FUNCTION/ALGORITHM
A hash function is any function that can be used to map digital data of arbitrary size to
digital data of fixed size, with slight differences in input data producing very big
differences in output data. The values returned by a hash function are called hash
values, hash codes, hash sums, or simply hashes. One practical use is a data structure
called a hash table, widely used in computer software for rapid data lookup. Hash
functions accelerate table or database lookup by detecting duplicated records in a large
file. An example is finding similar stretches in DNA sequences. They are also useful in
cryptography. A cryptographic hash function allows one to easily verify that some input
data matches a stored hash value, but makes it hard to reconstruct the data from the
hash alone. This principle is used by the PGP algorithm for data validation and by many
password checking systems.
Hash functions are related to (and often confused with) checksums, check digits,
fingerprints, randomization functions, error-correcting codes, and ciphers. Although
these concepts overlap to some extent, each has its own uses and requirements and is
designed and optimized differently. The Hash Keeper database maintained by the
American National Drug Intelligence Center, for instance, is more aptly described as a
catalog of file fingerprints than of hash values.
A hash value can be used to uniquely identify secret information. This requires that the
hash function is collision resistant, which means that it is very hard to find data that
generate the same hash value. These functions are categorized into cryptographic hash
12

functions and provably secure hash functions. Functions in the second category are the
most secure but also too slow for most practical purposes. Collision resistance is
accomplished in part by generating very large hash values. For example SHA-1, one of the
most widely used cryptographic hash functions, generates 160 bit values.
Common functions:
• MD5
• SHA-1
• SHA-2
• SHA-3/Keccak
MAC algorithms
• DAA
• CBC-MAC
• HMAC
• OMAC/CMAC
• PMAC
• VMAC
• UMAC
• Poly1305-AES
12

PKIX Standards Participation
PKIX-1: Chaired and edited by Entrust
staff
PKIX-2: LDAP portion authored by
Sharon Boeyen
PKIX-3: CMP portion authored by
Carlisle Adams
PKIX-4: participation by Sharon
Boeyen others
PKIX-5: authored by Carlisle Adams,
13

Robert Zuccherato
PKIX-6: authored by Carlisle Adams,
Robert Zuccherato
PKIX Overview for IEEE: authored
by
Carlisle Adams and Steve Lloyd
13

Public Key Cryptography Standard (PKCS)
PKCS #1 v2.1 RSA Cryptography Standard[1] See RFC 3447. Defines the
mathematical properties and format of RSA public and private keys (ASN.1-encoded in
clear-text), and the basic algorithms and encoding/padding schemes for performing RSA
encryption, decryption, and producing and verifying signatures.
PKCS #2 - Withdrawn No longer active as of 2010. Covered RSA encryption of
message digests; subsequently merged into PKCS #1.
PKCS #3 v1.4 Diffie–Hellman Key Agreement Standard[2] A cryptographic protocol that
allows two parties that have no prior knowledge of each other to jointly establish a
shared secret key over an insecure communications channel.
PKCS #4 - Withdrawn No longer active as of 2010. Covered RSA key syntax;
subsequently merged into PKCS #1.
PKCS #5 v2.0 Password-based Encryption Standard[3] See RFC 2898 and PBKDF2.
PKCS #6 v1.5 Extended-Certificate Syntax Standard[4] Defines extensions to the old
v1 X.509 certificate specification. Obsoleted by v3 of the same.
PKCS #7 v1.5 Cryptographic Message Syntax Standard[5] See RFC 2315. Used to sign
and/or encrypt messages under a PKI. Used also for certificate dissemination (for
instance as a response to a PKCS#10 message). Formed the basis for S/MIME, which is as
of 2010 based on RFC 5652, an updated Cryptographic Message Syntax Standard (CMS).
Often used for single sign-on.
PKCS #8 v1.2 Private-Key Information Syntax Standard[6] See RFC 5208. Used to carry
private certificate key pairs (encrypted or unencrypted).
PKCS #9 v2.0 Selected Attribute Types[7] See RFC 2985. Defines selected attribute
14

types for use in PKCS #6 extended certificates, PKCS #7 digitally signed messages, PKCS #8
private-key information, and PKCS #10 certificate-signing requests.
PKCS #10 v1.7 Certification Request Standard[8] See RFC 2986. Format of
messages sent to a certification authority to request certification of a public key. See
certificate signing request.
PKCS #11 v2.30 Cryptographic Token Interface[9] Also known as
Cryptoki. An API defining a generic interface to cryptographic tokens (see also
Hardware Security Module). Often used in single sign-on, public-key cryptography and
disk encryption[10] systems. RSA Security has turned over further development of the
PKCS#11 standard to the OASIS PKCS 11 Technical Committee.
PKCS #12 v1.0 Personal Information Exchange Syntax Standard[11] Defines a file
format commonly used to store private keys with accompanying public key certificates,
protected with a password-based symmetric key. PFX is a predecessor to PKCS #12. This
container format can contain multiple embedded objects, such as multiple certificates.
Usually protected/encrypted with a password. Usable as a format for the Java key store
and to establish client authentication certificates in Mozilla Firefox. Usable by Apache
Tomcat.
PKCS #13 – Elliptic Curve Cryptography Standard (Apparently abandoned, only
reference is a proposal from 1998.)[12]
PKCS #14 – Pseudo-random Number Generation (Apparently abandoned, no
documents exist.)
PKCS #15 v1.1 Cryptographic Token Information Format Standard[13] Defines a
standard allowing users of cryptographic tokens to identify themselves to applications,
independent of the application's Cryptoki implementation (PKCS #11) or other API. RSA
has relinquished IC-card-related parts of this standard to ISO/IEC 7816-15.
14

is an Internet protocol used for obtaining X.509 digital certificates in a public key
infrastructure (PKI). It is described in RFC 4210 and is one of two protocols so far to use
the Certificate Request Message Format (CRMF), described in RFC 4211, with the other
protocol being Certificate Management over CMS (CMC), described in RFC 5273. An
obsolete version of CMP is described in RFC 2510, the respective CRMF version in RFC
2511
An EE can utilize CMP to obtain certificates from the CA. This can be done through an
initial registration/certification, a key pair update or a certificate update message
sequence. By means of a revocation request it can also get one of its own certificates
revoked. Using a cross-certification request a CA can get a certificate signed by
another CA. In case an EE has lost its private key and it is stored by the CA, it might be
recovered by requesting a key pair recovery.
Sample Implementations
• Nexus Certificate Manager supports CMP.
• The library cryptlib provides CMP support.
• EJBCA, a CA, implements a subset[2] of the CMP functions.
• OpenSSL is capable of producing and parsing CMP messages, using an additional
15

patch.[3]
• RSA's BSAFE Java Library provides CMP support.
15

XML Key Management Specification (XKMS)
uses the web services framework to make it easier for developers to secure inter-application
communication using public key infrastructure (PKI). XML Key Management
Specification is a protocol developed by W3C which describes the distribution and
registration of public keys. Services can access an XKMS compliant server in order to
receive updated key information for encryption and authentication.
The X-KRSS defines the protocols needed to register public key information. X-KRSS can
generate the key material, making key recovery easier than when created manually.
The X-KISS outlines the syntax that applications should use to delegate some or all of the
tasks needed to process the key information element of an XML signature to a trust
service.
In both cases the goal of XKMS is to allow all the complexity of traditional PKI
implementations to be offloaded from the client to an external service. While this
approach was originally suggested by Diffie and Hellman in their New Directions paper
this was generally considered impractical at the time leading to commercial
development focusing on the certificate based approach proposed by Loren Kohnfelder.
XML Signature (also called XMLDSig, XML-DSig, XML-Sig) defines an XML syntax for
digital signatures and is defined in the W3C recommendation XML Signature Syntax and
Processing. Functionally, it has much in common with PKCS#7 but is more extensible and
16

geared towards signing XML documents. It is used by various Web technologies such as
SOAP, SAML, and others.
XML signatures can be used to sign data–a resource–of any type, typically XML
documents, but anything that is accessible via a URL can be signed. An XML signature
used to sign a resource outside its containing XML document is called a detached
signature; if it is used to sign some part of its containing document, it is called an
enveloped signature; if it contains the signed data within itself it is called an enveloping
signature.
XML Encryption, also known as XML-Enc, is a specification, governed by a W3C
recommendation, that defines how to encrypt the contents of an XML element.
Although XML Encryption can be used to encrypt any kind of data, it is nonetheless
known as XML Encryption because an XML element (either an EncryptedData or
EncryptedKey element) contains or refers to the cipher text, keying information, and
algorithms.
Both XML Signature and XML Encryption use the KeyInfo element, which appears as the
child of a SignedInfo, EncryptedData, or EncryptedKey element and provides information
to a recipient about what keying material to use in validating a signature or decrypting
encrypted data.
The KeyInfo element is optional: it can be attached in the message, or be delivered
through a secure channel.
XML Encryption is different from and unrelated to Transport Layer Security, which is used
to send encrypted messages (including xml content, both encrypted and otherwise) over
the internet. It has been reported that this specification has severe security concerns.
16

Online Certificate Status Protocol (OCSP)
The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining
the revocation status of an X.509 digital certificate. It is described in RFC 6960 and is on
the Internet standards track. It was created as an alternative to certificate revocation
lists (CRL), specifically addressing certain problems associated with using CRLs in a public
key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and
are usually communicated over HTTP. The request/response nature of these messages
leads to OCSP servers being termed OCSP responders.
OCSP can support more than one level of CA. OCSP requests may be chained between
peer responders to query the issuing CA appropriate for the subject certificate, with
responders validating each other's responses against the root CA using their own OCSP
requests.
An OCSP responder may be queried for revocation information by delegated path
validation (DPV) servers. OCSP does not, by itself, perform any DPV of supplied
certificates.
The key that signs a response need not be the same key that signed the certificate. The
certificate's issuer may delegate another authority to be the OCSP responder. In this
case, the responder's certificate (the one that is used to sign the response) must be
issued by the issuer of the certificate in question, and must include a certain extension
that marks it as an OCSP signing authority.
17

Certificate Format Standard (X.509)
In cryptography, X.509 is an ITU-T standard for a public key infrastructure (PKI) and
Privilege Management Infrastructure (PMI). X.509 specifies, amongst other things,
standard formats for public key certificates, certificate revocation lists, attribute
certificates, and a certification path validation algorithm.
X.509 was initially issued on July 3, 1988 and was begun in association with the X.500
standard. It assumes a strict hierarchical system of certificate authorities (CAs) for
issuing the certificates. This contrasts with web of trust models, like PGP, where anyone
(not just special CAs) may sign and thus attest to the validity of others' key certificates.
Version 3 of X.509 includes the flexibility to support other topologies like bridges and
meshes.[1] It can be used in a peer-to-peer, OpenPGP-like web of trust, but was rarely
used that way as of 2004. The X.500 system has only ever been implemented by
sovereign nations for state identity information sharing treaty fulfillment purposes, and
the IETF's Public-Key Infrastructure (X.509), or PKIX, working group has adapted the
standard to the more flexible organization of the Internet. In fact, the term X.509
certificate usually refers to the IETF's PKIX Certificate and CRL Profile of the X.509 v3
certificate standard, as specified in RFC 5280.,[2] commonly referred to as PKIX for Public
Key Infrastructure (X.509).
In the X.509 system, a certification authority issues a certificate binding a public key to a
18

particular distinguished name in the X.500 tradition, or to an alternative name such as an
e-mail address or a DNS entry.
An organization's trusted root certificates can be distributed to all employees so that they
can use the company PKI system. Browsers such as Internet Explorer, Firefox, Opera,
Safari and Chrome come with a predetermined set of root certificates pre-installed, so
SSL certificates from larger vendors will work instantly; in effect the browsers' developers
determine which CAs are trusted third parties for the browsers' users.
X.509 also includes standards for certificate revocation list (CRL) implementations, an
often neglected aspect of PKI systems. The IETF-approved way of checking a certificate's
validity is the Online Certificate Status Protocol (OCSP). Firefox 3 enables OCSP checking
by default along with versions of Windows including Vista and later.
Structure of a certificate
The structure foreseen by the standards is expressed in a formal language, namely
Abstract Syntax Notation One.
The structure of an X.509 v3 digital certificate is as follows:
Certificate
Version
Serial Number
Algorithm ID
Issuer
Validity
Not Before
Not After
Subject
Subject Public Key Info
Public Key Algorithm
Subject Public Key
Issuer Unique Identifier (optional)
Subject Unique Identifier (optional)
Extensions (optional)
...
Certificate Signature Algorithm
Certificate Signature
Each extension has its own id, expressed as Object identifier, which is a set of values,
together with either a critical or non-critical indication. A certificate-using system MUST
reject the certificate if it encounters a critical extension that it does not recognize, or a
critical extension that contains information that it cannot process. A non-critical
extension MAY be ignored if it is not recognized, but MUST be processed if it is
recognized.
18

Digital Certificate vs Certificate Store
Digital Certificate
is an electronic document used to prove ownership of a public key. The
certificate includes information about the key, information about its owner's
identity, and the digital signature of an entity that has verified the certificate's
contents are correct. If the signature is valid, and the person examining the
certificate trusts the signer, then they know they can use that key to
communicate with its owner.
In a typical public-key infrastructure (PKI) scheme, the signer is a certificate
authority (CA), usually a company such as VeriSign which charges customers to
issue certificates for them. In a web of trust scheme, the signer is either the key's
owner (a self-signed certificate) or other users (endorsements) whom the
person examining the certificate might know and trust.
Certificates are an important component of Transport Layer Security (TLS,
sometimes called by its older name SSL), where they prevent an attacker from
impersonating a secure website or other server. They are also used in other
important applications, such as email encryption and code signing.
Certificate Store:
manages digital certificate transactions for many applications (e.g. Internet
Explorer, Cisco VPN) for various type of certificate for secure manner.
19

is in multiple form of store such as file (java key store), registry, embedded in
cryptographic service provider.
Common reside on operating system to secure user’s private key and their
associate digital certificate.
19

Digital Certificate
The X.509v3 standard is a standard that governs digital certificates generally. It does not
provide a standard for certificates specific to S/MIME certificates. Information about
digital certificates specific to S/MIME is explained in the S/MIME RFCs.
Certificate Required Field(s)
• Serial Number is serialized number to identify certificate issued by
Certificate Authority.
• Certificate Algorithm Identifier is an algorithm used to verify CA
digital signature.
• Issuer is a Distinguish Name (X.500) of Certificate Authority and
Referral.
• Validity Period is a period of usable of this certificate.
Issue Date is a issuing date/time of this certificate which time
stamp by Certificate Authority.
Expire Date is a expired date/time of this certificate.
• Subject Name is a name of user, computer, server which certify
identity by Certificate Authority.
• Subject Public Key is a subject’s public key entity and its algorithm.
20

• CA Digital Signature is a finger print of this certificate which encrypted
by Certificate Authority Private Key (also called Digital Signature).
• Issuer unique identifier is information that can be used to uniquely
identify the issuer of the digital certificate.
• Subject unique identifier is information that can be used to uniquely
identify the owner of the digital certificate.
• Extensions Entity is additional information that is related to the use
and handling of the certificate.
• Application policies
Application policies are settings that inform a target that the
subject holds a certificate that can be used to perform a
specific task. They are represented in a certificate by an object
identifier that is defined for a given application. This object
identifier is included in the issued certificate. When a subject
presents its certificate, the certificate can be examined by the
target to verify the application policy and determine whether
the subject can perform the requested action.
• Issuance policies
Issuance policies, also referred to as certificate policies, define
the measures that are used to identify the subject of the
certificate and thereby define the level of assurance for an
issued certificate. For example, your organization might
require a face-to-face meeting before the certificate is issued
to provide for a higher level of assurance for the issued
certificate.
• Certificate subject type
The certificate subject type, also referred to as the certificate
template information, defines the purpose of a certificate or
certificate template.
The certificate subject type extension cannot be edited. If an
administrator requires a specific subject type to be applied to
a certificate, the administrator should duplicate a certificate
template that includes the required subject type.
• Key usage
A certificate enables the subject to perform a specific task. To
help control the usage of a certificate outside its intended
purpose, restrictions are automatically placed on certificates.
Key usage is a restriction method that determines what a
certificate can be used for. It allows the administrator to issue
certificates that can only be used for specific tasks or
certificates that can be used for a broad range of functions. If
no key usage is specified, the certificate can be used for any
purpose.
For signatures, key usage can be limited to one or more of the
following purposes:
20

Digital signature
Signature is a proof of origin (nonrepudiation
Certificate signing
CRL signing
• For encryption key usage, the following options are available:
Key exchange without key encryption
Key exchange only with key encryption
• Attributes
In addition to the information required by the certification
authority (CA) to construct the requested certificate, a
certificate request also includes attributes that describe how
the certificate request was created. The certificate request
attributes include the operating system version and
application used to create the request, the cryptographic
service provider used to generate the key pair, the certificate
template the request is based on, and other details.
Attributes are automatically added to certificate requests that
are created by using the Certificates snap-in and are stored in
the CA database with each certificate request.
• Additional references
Request a Certificate
20

Digital certificates and digital signing of an e-mail message
A public key to a user's private key allows a recipient to authenticate and validate a
sender's message. Digital certificates provide support to public key cryptography by
providing a reliable means to distribute and access public keys. When a sender is signing
a message, the sender provides the private key that is associated with the public key
available on the digital certificate. In turn, when the recipient is validating a digital
signature on a message, the recipient is obtaining the public key to perform that
operation from the sender's digital certificate. The above figure shows the sequence of
signing with the addition of the supporting elements of digital certificates.
1. Message is captured.
2. Hash value of the message is calculated.
3. Sender's private key is retrieved from the sender's digital certificate.
4. Hash value is encrypted with the sender's private key.
5. Encrypted hash value is appended to the message as a digital signature.
6. Message is sent.
21

Digital certificates and verifying a digital signature of an e-mail message
The above figure shows the sequence of verifying with the addition of the supporting
elements of digital certificates.
1. Message is received.
2. Digital signature containing encrypted hash value is retrieved from the message.
3. Message is retrieved.
4. Hash value of the message is calculated.
5. Sender's public key is retrieved from the sender's digital certificate.
6. Encrypted hash value is decrypted with the sender's public key.
7. Decrypted hash value is compared against the hash value produced on receipt.
8. If the values match, the message is valid.
22

Key Store (Java – JKS)
is a repository of security certificates – either authorization certificates or public key
certificates – used for instance in SSL encryption.
In Oracle WebLogic Server, a file with extension jks serves as keystore.
The Java Development Kit maintains a CA keystore in folder jre/lib/security/cacerts. JDKs
provide a tool named keytool to manipulate the keystore. keytool has no functionality to
extract the private key out of the keystore, but this is possible with third-party tools like
jksExportKey, CERTivity, Portecle and KeyStore Explorer.
23

Certificate Store
Is store a certificate locally on the computer or device that requested it or, in the case of
a user, on the computer or device that the user used to request it. The storage location
is called the certificate store. A certificate store will often have numerous certificates,
possibly issued from a number of a different certification authorities.
Using the Certificates snap-in on Microsoft Windows, you can display the certificate
store for a user, a computer, or a service according to the purpose for which the
certificates were issued or by using their logical storage categories. When you display
certificates according to their storage categories, you can also choose to display the
physical stores, showing the certificate storage hierarchy. (This is recommended for
advanced users only.)
If you have the user rights to do so, you can import or export certificates from any of the
folders in the certificate store. Additionally, if the private key associated with a
certificate is marked as available for export, you can export both into a PKCS #12 file.
Windows can also publish certificates to Active Directory. Publishing a certificate in
Active Directory enables all users or computers with adequate permissions to retrieve
the certificate as needed.
Certificates can be displayed by purpose or by logical stores, as shown in the following
table. Displaying certificates by logical stores is the Certificates default. (Note that the
list of certificate purpose stores does not include all the possible purpose stores.)
24

Display by Folder name Contents
Logical Store Personal Certificates associated with private keys to
which you have access. These are the certificates that have been issued to you,
or to the computer or service for which you
are managing certificates.
Note to administrators: Computers in a
Windows Server 2003 Active Directory domain can have certificates automatically
placed in this store through the use of Group
Policy-based auto-enrollment. For more information,
see Automatic certificate request settings.
Trusted Root Certification Authorities
Implicitly trusted certification authorities.
Includes all of the certificates in the Third-Party Root Certification Authorities store
plus root certificates from your organization
and Microsoft.
If you are an administrator and want to add
third-party certification authority certificates to this store for all computers
in a Windows Server 2003 Active Directory
domain, you can use Group Policy to distribute trusted root certificates to your
organization.
For more information, see Trusted root
certification authority policy.
Enterprise Trust
A container for certificate trust lists. A
certificate trust list provides a mechanism for trusting self-signed root certificates
from other organizations and limiting the
purposes for which these certificates are trusted.
For more information about Enterprise trust
see Enterprise trust policy.
Intermediate Certification Authorities
Certificates issued to subordinate
certification authorities.
Trusted People
Certificates issued to people or end entities
that are explicitly trusted. Most often these are self-signed certificates or
24

certificates explicitly trusted in an application
such as Microsoft Outlook.
Other People
Certificates issued to people or end entities
that are implicitly trusted. These certificates must be part of a trusted certification
hierarchy.
Most often these are cached certificates for
services like Encrypting File System, where certificates are used for
creating authorization for decrypting an
encrypted file.
Trusted Publishers
Certificates from certification authorities
that are trusted by Software Restriction policies.
Disallowed Certificates
These are certificates that you have explicitly
decided not to trust using either Software Restriction policy
or by clicking Do not trust this certificate
when the decision is presented to you in mail or a Web browser.
Third-Party Root Certification Authorities
Trusted root certificates from certification
authorities other than Microsoft and your organization.
Certificate Enrollment Requests
Pending or rejected certificate requests.
Active Directory User Object
Certificates associated with your user object
and published in Active Directory.
Purpose
Server Authentication
Certificates that server programs use to
authenticate themselves to clients.
Client Authentication
Certificates that client programs use to
24

authenticate themselves to servers.
Code Signing
Certificates associated with key pairs used to
sign active content.
Secure Email
Certificates associated with key pairs used to
sign e-mail messages.
Encrypting File System
Certificates associated with key pairs that
encrypt and decrypt the symmetric key used for encrypting and
decrypting data by Encrypting File System
(EFS).
File Recovery
Certificates associated with key pairs that
encrypt and decrypt the symmetric key used for recovering
encrypted data by Encrypting File System
(EFS).
When you look at the contents of a certificate store in Logical Store mode, you will
occasionally see what appears to be two copies of the same certificate in the store. This
occurs because the same certificate is stored in separate physical stores under a logical
store. When the contents of the physical certificates stores are combined into one logical
store view, both instances of the same certificate are displayed.
You can verify this by setting the view option to show the physical certificate stores and
then noting that the certificate is stored in separate physical stores under the same
logical store. You can verify that it is the same certificate by comparing the serial
numbers.
For more information, see Generating encryption keys and certificate requests, Importing
and exporting certificates, Display certificate stores in Purpose mode, Display certificate
stores in Logical Store mode, Display archived certificates, Display certificate stores
storage structure
24

Cryptography Service Provider (CSP)
In Microsoft Windows, a Cryptographic Service Provider (CSP) is a software library that
implements the Microsoft CryptoAPI (CAPI). CSPs implement encoding and decoding
functions, which computer application programs may use, for example, to implement
strong user authentication or for secure email.
CSP contains implementations of cryptographic standards and algorithms. At a
minimum, a CSP consists of a dynamic-link library (DLL) that implements the functions in
CryptoSPI (a system program interface). Most CSPs contain the implementation of all of
their own functions. Some CSPs, however, implement their functions mainly in a
Windows-based service program managed by the Windows service control manager.
Others implement functions in hardware, such as a smart card or secure coprocessor. If
a CSP does not implement its own functions, the DLL acts as a pass-through layer,
facilitating the communication between the operating system and the actual CSP
implementation.
CSPs are independent modules that can be used by different applications. A user
program calls CryptoAPI functions and these are redirected to CSPs functions. Since CSPs
are responsible for implementing cryptographic algorithms and standards, applications
do not need to be concerned about security details. Furthermore, one application can
define which CSP it is going to use on its calls to CryptoAPI. In fact, all cryptographic
25

activity is implemented in CSPs. CryptoAPI only works as a bridge between the
application and the CSP.
There are many different standard data formats and protocols. These are generally
organized into groups or families, each of which has its own set of data formats and way
of doing things
Key exchange algorithm Each provider type specifies
one and only one key exchange algorithm. Every CSP of a particular type must
implement this algorithm.
Applications specify the key exchange algorithm to use by selecting a CSP of
the appropriate provider type.
Digital signature algorithm Each provider type specifies
one and only one digital signature algorithm. Every CSP of a particular type
must implement this
algorithm. Applications specify the digital signature algorithm to use by selecting a
CSP of the appropriate
provider type.
Key BLOB formats The provide type determines
the format of the key BLOB used to export keys from the CSP and to import keys into a
CSP.
Digital signature format The provider type determines
the digital signature format. This ensures that a signature produced by a CSP of a given
provider type can be verified
by any CSP of the same provider type.
Session key derivation scheme The provider type determines
the method used to derived a session key from a hash.
Key length Some provider types specify
the length of public/private key pairs and the session keys.
The main use of third-party CSPs is to interface with external cryptography hardware such
as hardware security modules (HSM) or smart cards.
Smart Card CSP
These cryptographic functions can be realized by a smart card, thus the Smart Card CSP is
the Microsoft way of a PKCS#11. Microsoft Windows is identifying the correct Smart Card
CSP, which have to be used, analyzing the answer to reset (ATR) of the smart card, which
is registered in the Windows Registry. Installing a new CSP, all ATRs of the supported
smart cards are enlisted in the registry.
25

Java Cryptography Architecture (JCA)
The JCA is a major piece of the platform, and contains a provider architecture and a
set of APIs for digital signatures, message digests (hashes), certificates and certificate
validation, encryption (symmetric/asymmetric block/stream ciphers), key generation
and management, and secure random number generation, to name a few. These APIs
allow developers to easily integrate security into their application code. The architecture
was designed around the following principles:
• Implementation independence: Applications do not need to implement security
algorithms. Rather, they can request security services from the Java platform.
Security services are implemented in providers (see below), which are plugged into
the Java platform via a standard interface. An application may rely on multiple
independent providers for security functionality.
• Implementation interoperability: Providers are interoperable across applications.
Specifically, an application is not bound to a specific provider, and a provider is not
bound to a specific application.
• Algorithm extensibility: The Java platform includes a number of built-in providers
that implement a basic set of security services that are widely used today. However,
some applications may rely on emerging standards not yet implemented, or on
proprietary services. The Java platform supports the installation of custom providers
that implement such services.
26

Design Principles
The JCA was designed around these principles:
• implementation independence and interoperability
• algorithm independence and extensibility
Implementation independence and algorithm independence are complementary; you can
use cryptographic services, such as digital signatures and message digests, without
worrying about the implementation details or even the algorithms that form the basis for
these concepts. While complete algorithm-independence is not possible, the JCA
provides standardized, algorithm-specific APIs. When implementation-independence is
not desirable, the JCA lets developers indicate a specific implementation.
Algorithm independence is achieved by defining types of cryptographic engines
(services), and defining classes that provide the functionality of these cryptographic
engines. These classes are called engine classes, and examples are the MessageDigest,
Signature, KeyFactory, KeyPairGenerator, and Cipher classes.
Implementation independence is achieved using a provider-based architecture. The
term Cryptographic Service Provider (CSP) (used interchangeably with provider in this
document) refers to a package or set of packages that implement one or more
cryptographic services, such as digital signature algorithms, message digest algorithms,
and key conversion services. A program may simply request a particular type of object
(such as a Signature object) implementing a particular service (such as the DSA signature
algorithm) and get an implementation from one of the installed providers. If desired, a
program may instead request an implementation from a specific provider. Providers may
be updated transparently to the application, for example when faster or more secure
versions are available.
Architecture
Cryptographic Service Providers
java.security.Provider is the base class for all security providers. Each CSP contains an
instance of this class which contains the provider's name and lists all of the security
services/algorithms it implements. When an instance of a particular algorithm is needed,
the JCA framework consults the provider's database, and if a suitable match is found, the
instance is created.
26

Key type and cryptographic service provider type
Certificates contain public key information that is used to encrypt or verify the digital
signature of information. Clients store this certificate in their certificate store and also
store data that indicates which cryptographic service provider (CSP) stores the
associated private key. This CSP could store the private key in memory, on disk, or on a
hardware key store, such as a smart card. This allows the client to perform any public-key
cryptography action based on the key pair. However, keys are created differently,
depending on their purpose. Some keys will work for encrypting data but not signing
data and vice versa. This is why key type and cryptographic service provider type must
be configured correctly.
Key type
When a public/private key pair is generated, several types of keys can be created. Keys
can be created to allow their use with encryption, digital signatures, or both. Certificate
templates can be configured for a key purpose of encryption, signature, signature and
encryption, or signature and smartcard logon. This setting is labeled Purpose in the
Certificate Templates console.
Cryptographic service provider type
Cryptographic service providers (CSPs) are hardware and software components of
Windows operating systems that provide generic cryptographic functions. These CSPs
27

can be written to provide a variety of encryption and signature algorithms. Each of the
CSPs that are configured to be used by a certificate template can potentially support
different cryptographic algorithms and, therefore, different key lengths. This means that
certificate templates must be configured to support one or more CSPs. Selecting specific
CSPs allows the administrator to control what algorithms and key lengths are used with
this certificate. Windows Server 2003 family includes a number of CSPs, and others can
be added for enhanced functionality.
27

Certificate Utility (CertUtil)
certutil can be used for a variety of tasks to manage certificates and keys, such as
generating certificate requests and removing certificates from the certificate database.
Some of the most common options are listed in List below “certutil Options”. For the full
list of commands and arguments, run certutil -H from the command line.
• certutil Options Description
• certutil -L -d . Lists the certificates in the
database.
• certutil -L -d . -n cert_name Pretty prints the specified
certificate; the cert_name can specify either a CA certificate or a client certificate.
• certutil -L -d . -n cert_name certfile.asc Exports the specified
certificate out of the database to ASCII (PEM) format.
• certutil -L -d . -n cert_name -r certfile.bin Exports the specified
certificate out of the database to binary format; this can be used with Directory
Server attributes
such as
userCertificate;binary.
28

Web Certificate Management
• is a management tool for manage certificate (request, revoke, verify) with
Certificate Authority (CA).
• provides Single Point of Service and registration administrative service for
certificate management with batch operation capability.
• Audits operation and reporting facility for company compliance.
• integrates application, web service and certificate authority function with in
one web portal.
• Registration Authority (RA)
• Web Portal Web Service
• CSP Application Protocol Interface (API)
• Certificate Authority (CA)
29

Web Certificate Management Component(s)
- Web Server is presentation layer to build and transform data from to web browser.
- Application Server provide application layer to construct, execute object and
command in prior to communicate with CA.
- Web Portal for Certificate Management
- Web Portal for Service Management
- Web Service for Certificate Management
- CSP Interface is a connection and interfacing that allow web application to call CSP’s
Services.
- Active Directory as User and Certificate Repository provide repository store point for
both user(s) and certificate(s) on Public Key Infrastructure System.
- Active Directory Certificate Services acts in the role of Certificate Authority, which
sign and issue user / entity’s certificate.
30

Web Certificate Management Architecture
The architecture is designed on security best practice.
A Web service is most commonly implemented as a wrapper—that is, as an interface
between a client consuming the service and back-end business logic components doing
the actual work. A Web service acts as a trust boundary or interface in your application
architecture. By its nature, a Web service acts as a gateway between trusted business
components and less trusted or untrusted client components. For this reason, it is
impossible to think about the security of a Web service without also thinking about
authentication, authorization, protection of sensitive data on the network, and handling
potentially malicious input. Each of these areas represents key decisions you will need to
make in order to maintain the security of your application.
First Tier (Web Server and Public Directory)
Web Server provide data and presentation dynamic, flexibility interface. In this Tier, both
Web Server and Active Directory is intend to provide public information query service
and act as a perimeter zone. All user need an authentication in prior to request for
services with secure communication is essential as such protocol like SSL, LDAP or TLS.
Second Tier (Web Server and Public Directory)
Upon REST (REpresentation State Transfer) design, the server side reside of the
application state and functionality are divided into resources. A resource is an item of
31

interest, a conceptual identity that is exposed to the clients. Example resources include
application objects, database records, algorithms, and so on. Every resource is uniquely
addressable using a URI (Universal Resource Identifier). All resources share a uniform
interface for the transfer of state between client and server. Standard HTTP methods such
as GET, PUT, POST, and DELETE are used. Hypermedia is the engine of the application
state, and resource representations are interconnected by hyperlinks.
CA’s Key Storage Location
The HSM would play a role of Cryptographic Service Provider and Secure Key Storage
Location with strong hardware security regarding to FIPS 140-2 Level 3 standard.
31

Web Service Standard
makes functional building-blocks accessible over standard Internet protocols
independent of platforms and programming languages.
Service Oriented Architecture (SOA)
- a solution to make service consumers/providers communicate.
Web Service Description Language (WSDL)
- a language that describes the provider service.
Simple Object Access Protocol (SOAP)
- a XML based protocol 'wrapper' used by the services to send messages.
Works in conjunction with WSDL as to provide parameters.
REpresentational State Transfer (REST)
- a protocol design on pattern that is similar to SOAP in function but
avoids the XML
JavaScript Object Notation (JSON)
- a google's object alternative to XML that uses javascript function to
interpret request/response parameter
32

User Interface and Menu
Accessing User Interface by open
https://www.gprocurement.go.th:8084/EGP3CA/index.jsp
User interface consists of 4 mains, as following:
• Home
• Web Services
• Certificate Request
• Certificate Revoke
• Certificate Verify
• Certificate Renew
• Administratives
• Batch Operation
• Email Configuration
• Log Configuration
• Log Forwarding
• Report Configuration
• Daily Report
• Contact Us
33

Web Services – Functionality
• Certificate Request – to request a new user’s certificate for new user.
• Certificate Revoke – to revoke a existing user’s certificate.
• Certificate Verify – to verify the status and validity of a existing user’s
certificate.
• Certificate Renew – to renew a user’s certificate (auto revoke existing).
34

Web Administrative – Functionality
• Batch Operation – a batch function page allows administrator to perform
certificate function on a multiple entry.
• Email Configuration – a configuration page for email notification parameters.
• Log Configuration – a configuration page for system logging parameters.
• Log Forwarding – a configuration page for log forwarding parameters.
• Report Configuration – a configuration page for report parameters.
• Daily Report – a report generating page.
35

Course: Digital Certificate Management – Public Key Infrastructure
Day 2 : Agenda
Chapter 6: Certificate Services
Chapter 7: Web Service (WSDL) Caller
Chapter 8: Certificate Installation
Chapter 9: System Configuration
https://docs.oracle.com/javase/7/docs/technotes/guides/security/certpath/CertPathPro
gGuide.html
36

Certificate Request
In order to perform certificate request, system require an existing user credential and
entry on certificate repository (Active Directory), since system is performing user entity
check before load user’s information (such as User’s Name, Surname, email address,
role, public key) to be constructing user’s certificate.
To request a new user certificate, administrator require to fill-in the request form:
• User Identification – is an identity of user, which may be user’s login name.
• Pass Phase – is a passphrase for retrieve certificate and import certificate in to user’s
machine.
To submit request by press “Process” button.
The Return from the system will show the downloadable link for user’s certificate in
PFX/P12 format. This file will deliver to user for certificate installation which require
passphrase for installation.
37

38

39

Certificate Revoke
In order to perform certificate revoke, system require that user need to have both
existing credential and entry on certificate repository (Active Directory), and valid
certificate which to be revoke.
To revoke a user certificate, administrator require to fill-in the revoke form:
• Certificate Serial Number – is an identity(serial number) of user’s certificate, which
one user may have more than one certificate.
• Revoke reason – is a reason for revoking certificate.
Following reason code are available:
• Unspecified
• Key Compromise
• CA Compromise
• Change of Affiliation
• Superseded
• Cease of Operation
To submit request by press “Send” button.
40

The Return from the system will show the downloadable link for Certificate Revocation
List file. This file will publish and distribute to server and user for certificate verification
purpose.
40

41

42

Certificate Verification
In order to perform certificate verification, system require that user need to have both
existing user credential and entry on certificate repository (Active Directory), otherwise
system will notify for error on verify both user entity and user’s certificate is not existing.
To verify a user certificate, administrator require to fill-in the request form:
• Certificate Serial Number – is an identity(serial number) of user’s certificate, which
one user may have more than one certificate.
Note: System will check both user entity on certificate repository and validity of user’s
certificate found on system.
The Return from the system will show the status of user’s certificate.
43

44

45

Certificate Renew
In order to perform certificate renewal, system require that user need to have both
existing user credential and entry on certificate repository (Active Directory), since
system is performing user entity check before load user’s information (such as User’s
Name, Surname, email address, role, public key) to be constructing user’s certificate.
To request a new user certificate, administrator require to fill-in the request form:
• User Identification – is an identity of user, which may be user’s login name.
• Pass Phase – is a passphrase for retrieve certificate and import certificate in to user’s
machine.
Note: System will revoke any valid user’s certificate found on system, then issue a new
certificate.
The Return from the system will show the downloadable link for user’s certificate in
PFX/P12 format. This file will deliver to user for certificate installation which require
passphrase for installation. And show the downloadable link for Certificate Revocation
List file. This file will publish and distribute to server and user for certificate verification
46

purpose.
46

47

48

WSDL Concept and Tools
Web Services Description Language (WSDL) is an XML-based language for describing
Web services and defines services as collections of network endpoints, or ports by using
the following elements in the definition of network services:
Types– a container for data type definitions using some type system (such as
XSD).
Message– an abstract, typed definition of the data being communicated.
Operation– an abstract description of an action supported by the service.
Port Type–an abstract set of operations supported by one or more endpoints.
Binding– a concrete protocol and data format specification for a particular port
type.
Port– a single endpoint defined as a combination of a binding and a network
address.
Service– a collection of related endpoints.
============= WSDL Sample=============
?xml version='1.0' encoding='UTF-8'?!-- Published by JAX-WS RI at http://jax-ws.dev.java.net.
RI's version is JAX-WS RI 2.2-hudson-740-. --
!-- Generated by JAX-WS RI at http://jax-ws.dev.java.net. RI's version is JAX-WS RI 2.2-hudson-
740-. --
49

definitions xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-
1.0.xsd xmlns:wsp=http://www.w3.org/ns/ws-policy
xmlns:wsp1_2=http://schemas.xmlsoap.org/ws/2004/09/policy
xmlns:wsam=http://www.w3.org/2007/05/addressing/metadata
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/
xmlns:tns=http://ws.service.certificate.mita29/
xmlns:xsd=http://www.w3.org/2001/XMLSchema xmlns=http://schemas.xmlsoap.org/wsdl/
targetNamespace=http://ws.service.certificate.mita29/
name=CertReqWstypesxsd:schemaxsd:import
namespace=http://ws.service.certificate.mita29/
schemaLocation=http://localhost:8084/EGP3CA/CertReqWs?xsd=1
//xsd:schema/typesmessage name=getStrmCertpart name=parameters
element=tns:getStrmCert //messagemessage name=getStrmCertResponsepart
name=parameters element=tns:getStrmCertResponse //messagemessage
name=getCertUrlpart name=parameters element=tns:getCertUrl //messagemessage
name=getCertUrlResponsepart name=parameters element=tns:getCertUrlResponse
//messageportType name=CertReqWsoperation name=getStrmCertinput
wsam:Action=http://ws.service.certificate.mita29/CertReqWs/getStrmCertRequest
message=tns:getStrmCert /output
wsam:Action=http://ws.service.certificate.mita29/CertReqWs/getStrmCertResponse
message=tns:getStrmCertResponse //operationoperation name=getCertUrlinput
wsam:Action=http://ws.service.certificate.mita29/CertReqWs/getCertUrlRequest
message=tns:getCertUrl /output
wsam:Action=http://ws.service.certificate.mita29/CertReqWs/getCertUrlResponse
message=tns:getCertUrlResponse //operation/portTypebinding
name=CertReqWsPortBinding type=tns:CertReqWssoap:binding
transport=http://schemas.xmlsoap.org/soap/http style=document /operation
name=getStrmCertsoap:operation soapAction= /inputsoap:body use=literal
//inputoutputsoap:body use=literal //output/operationoperation
name=getCertUrlsoap:operation soapAction= /inputsoap:body use=literal
//inputoutputsoap:body use=literal //output/operation/bindingservice
name=CertReqWsport name=CertReqWsPort
binding=tns:CertReqWsPortBindingsoap:address
location=http://localhost:8084/EGP3CA/CertReqWs //port/service/definitions
WSDL Test Tools
soapUI – a Java-based tool from Eviware
TestMaker – a Web service testing application from PushToTest. written in Jython
(Python written in Java).
WebInject – a super-lightweight testing tool that can automate the testing of
both Web services and Web applications. (command-line tool)
49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

Digital certificate management v1 (Draft)

More Related Content

What's hot

Viewers also liked

Similar to Digital certificate management v1 (Draft)

More from Avirot Mitamura

Recently uploaded

Digital certificate management v1 (Draft)