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'?>



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="CertReqWs"><types><xsd:schema><xsd:import

namespace="http://ws.service.certificate.mita29/"

schemaLocation="http://localhost:8084/EGP3CA/CertReqWs?xsd=1"

/></xsd:schema></types><message name="getStrmCert"><part name="parameters"

element="tns:getStrmCert" /></message><message name="getStrmCertResponse"><part

name="parameters" element="tns:getStrmCertResponse" /></message><message

name="getCertUrl"><part name="parameters" element="tns:getCertUrl" /></message><message

name="getCertUrlResponse"><part name="parameters" element="tns:getCertUrlResponse"

/></message><portType name="CertReqWs"><operation name="getStrmCert"><input

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" /></operation><operation name="getCertUrl"><input

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></portType><binding

name="CertReqWsPortBinding" type="tns:CertReqWs"><soap:binding

transport="http://schemas.xmlsoap.org/soap/http" style="document" /><operation

name="getStrmCert"><soap:operation soapAction="" /><input><soap:body use="literal"

/></input><output><soap:body use="literal" /></output></operation><operation

name="getCertUrl"><soap:operation soapAction="" /><input><soap:body use="literal"

/></input><output><soap:body use="literal" /></output></operation></binding><service

name="CertReqWs"><port name="CertReqWsPort"

binding="tns:CertReqWsPortBinding"><soap: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

Date post:	05-Jul-2015
Category:	Technology
Upload:	avirot-liangsiri
View:	253 times
Download:	4 times

Digital certificate management v1 (Draft)

Technology