Create self signed certification in linux with java keytool

#!/bin/bash
export PW=`cat password`

# Create a self signed key pair root CA certificate.
keytool -genkeypair -v \
-alias testca \
-dname "CN=testca, OU=Dev, O=inBay, L=Ottawa, ST=ON, C=CA" \
-keystore testca.jks \
-keypass:env PW \
-storepass:env PW \
-keyalg RSA \
-keysize 4096 \
-ext KeyUsage:critical="keyCertSign" \
-ext BasicConstraints:critical="ca:true" \
-validity 9999


# Export the exampleCA public certificate
keytool -export -v \
-alias testca \
-file testca.crt \
-keypass:env PW \
-storepass:env PW \
-keystore testca.jks \
-rfc

# Create a server certificate,
keytool -genkeypair -v \
  -alias localhost \
  -dname "CN=127.0.0.1, OU=Dev, O=inBay, L=Ottawa, ST=ON, C=CA" \
  -keystore localhost.jks \
  -keypass:env PW \
  -storepass:env PW \
  -keyalg RSA \
  -keysize 2048 \
  -validity 3650

# Create a certificate signing request
keytool -certreq -v \
  -alias localhost \
  -keypass:env PW \
  -storepass:env PW \
  -keystore localhost.jks \
  -file localhost.csr


# Tell testca to sign the localhost certificate. Note the extension is on the request, not the
# original certificate.
# Technically, keyUsage should be digitalSignature for DHE or ECDHE, keyEncipherment for RSA.

keytool -gencert -v \
  -alias testca \
  -keypass:env PW \
  -storepass:env PW \
  -keystore testca.jks \
  -infile localhost.csr \
  -outfile localhost.crt \
  -ext KeyUsage:critical="digitalSignature,keyEncipherment" \
  -ext EKU="serverAuth" \
  -rfc

# Tell localhost.jks it can trust testca as a signer.
keytool -import -v \
  -alias testca \
  -file testca.crt \
  -keystore localhost.jks \
  -storetype JKS \
  -storepass:env PW << EOF
yes
EOF

# Import the signed certificate back into localhost.jks
keytool -import -v \
  -alias localhost \
  -file localhost.crt \
  -keystore localhost.jks \
  -storetype JKS \
  -storepass:env PW

# List out the contents of localhost.jks just to confirm it.
# If you are using Play as a TLS termination point, this is the key store you should present as the server.
keytool -list -v \
  -keystore localhost.jks \
  -storepass:env PW

#First export key

keytool -importkeystore -srckeystore localhost.jks -destkeystore keystore.p12 -deststoretype PKCS12

#For apache ssl certificate file you need certificate only

openssl pkcs12 -in keystore.p12 -nokeys -out localserver.crt
#or ssl key file you need only keys
openssl pkcs12 -in keystore.p12 -nocerts -nodes -out localserver.key

How to create a web server SSL certificate manually

The Internet Information Server (IIS) and Microsoft Internet Security and Acceleration (ISA) provide wizards in the administration user interface to request and install SSL certificates. With this blog post I want to explain how to request a SSL server certificate manually. The manual steps are required if the Certification Authority (CA) is not available in the same forest as the IIS or ISA is a member of.

1. Creating an INF file to set the certificate properties

Use Notepad to modify the following sample INF file according to your needs. Safe the file as ssl.inf for example

[Version] Signature="$Windows NT$"

[NewRequest] 
Subject = "CN=SERVER.CONTOSO.COM"   ; For a wildcard use "CN=*.CONTOSO.COM" for example 
; For an empty subject use the following line instead or remove the Subject line entierely 
; Subject = 
Exportable = FALSE                  ; Private key is not exportable 
KeyLength = 2048                    ; Common key sizes: 512, 1024, 2048, 4096, 8192, 16384 
KeySpec = 1                         ; AT_KEYEXCHANGE 
KeyUsage = 0xA0                     ; Digital Signature, Key Encipherment 
MachineKeySet = True                ; The key belongs to the local computer account 
ProviderName = "Microsoft RSA SChannel Cryptographic Provider" 
ProviderType = 12 
SMIME = FALSE 
RequestType = CMC

; At least certreq.exe shipping with Windows Vista/Server 2008 is required to interpret the [Strings] and [Extensions] sections below

[Strings] 
szOID_SUBJECT_ALT_NAME2 = "2.5.29.17" 
szOID_ENHANCED_KEY_USAGE = "2.5.29.37" 
szOID_PKIX_KP_SERVER_AUTH = "1.3.6.1.5.5.7.3.1" 
szOID_PKIX_KP_CLIENT_AUTH = "1.3.6.1.5.5.7.3.2"

[Extensions] 
%szOID_SUBJECT_ALT_NAME2% = "{text}dns=computer1.contoso.com&dns=computer2.contoso.com" 
%szOID_ENHANCED_KEY_USAGE% = "{text}%szOID_PKIX_KP_SERVER_AUTH%,%szOID_PKIX_KP_CLIENT_AUTH%"

[RequestAttributes] 
CertificateTemplate= WebServer

Notes:

• leave off the Subject= line if you want the subject to be empty
• if you don’t need the template to be specified, remove the RequestAttributes section
• the specification of the enhanced key usage OID is not explicitly required since the EKU is defined in the certificate template. The OID in the INF file above is for explanatory purposes
• you can click on “OK” for the template not found UI from certreq if the client has no access to templates
• you can ignore the unreferenced “[Strings]” section dialog when it appears

2. Compiling the INF file into a REQ file

The following command-line command will generate key material and turn the INF file into a certificate request.

certreq –new ssl.inf ssl.req

Once the certificate request was created you can verify the request with the following command:

certutil ssl.req

3. Submitting the REQ file to the CA

If the CA is reachable via RPC over the network, use the following command to submit the certificate request to the CA:

certreq –submit ssl.req

You will get a selection dialog to select the CA from. If the CA is configured to issue certificates based on the template settings, the CA may issue the certificate immediately.

If RPC traffic is not allowed between the computer where the certificate request was created and the CA, transfer the certificate request to the CA and perform the above command locally at the CA.

If the certificate template name was not specified in the certificate request above, you can specify it as part of the submission command:

certreq -attrib "CertificateTemplate:webserver" –submit ssl.req

4. Installing the certificate at the IIS or ISA computer

Once the certificate was issued and is available as a file on the target computer, use the following command to install it.

certreq –accept ssl.cer

The installation actually puts the certificate into the computer’s personal store, links it with the key material created in step #1 and builds the certificate property. The certificate property stores information such as the friendly name which is not part of a certificate.

After performing steps 1 to 4 the certificate will show up in the IIS or ISA management interface and can be bound to a web site or a SSL listener.

How to add the certification to ubuntu trusted lis

1.     Copy your CA to dir /usr/local/share/ca-certificates/

2.     Use command:

sudo cp foo.crt /usr/local/share/ca-certificates/foo.crt

3.   Update the CA store:

sudo update-ca-certificates

To remove the list:

delete the file from /usr/local/share/ca-certificates

sudo update-ca-certificates --fresh

Windows 2016 ADFS 4.0 OpenID connector does not work with custom claims provider

Default install custom claims provider with ADFS 4.0 that OpenId client report error:

 MSIS9642: The request cannot be completed because an id token 

is required but the server was unable to construct an id token 

for the current user.

To fix this issue:

The root cause of MSIS9642 is that the new OpenID Connect Application Group features in ADFS 2016 need to issue an access token to your application. This token must include the users identity. In order to issue the token the subsystem must understand which claim in the inbound claims is used to uniquely identify the user.

A new property called AnchorClaimType has been added to the Claim Provider Trust model.

When ADFS is first installed it registers a built in Claim Provider Trust for AD AUTHORITY and sets the value for AnchorClaimType to

http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname

You can see this by using the powershell command get-adfsclaimsprovidertrust.

This is why OpenID works for when authenticating against Active Directory.



When you create a new Claim Provider Trust the system does not set an AnchorClaimType. The OpenID system can't issue a token because it does not know which inbound claim constitutes the unique user identity. This is why OpenID does not work when authenticating against an external Claim Provider trust.

In order to resolve this problem you need to take a few actions:

a) Verify that you are running Windows Server 2016 RTM Unfortunately the powershell attribute to set AnchorClaimType does not exist in the CTP, and the property cannot be set using the UI.

b) Choose a claim from the inbound token that represents the users identity and identify the claim type. In our case we were federating with an Azure Active Directory and chose name, and the type is foo://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

c) Set the AnchorTypeClaim for the Claim Provider Trust to the type selected by using powershell

set-adfsclaimsprovidertrust -targetidentifier identifier -AnchorClaimType  http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

(get identifier from powershell get-adfsclaimsprovidertrust)

set-adfsclaimsprovidertrust -targetidentifier http://idqidp.domain.com  -AnchorClaimType  http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname

Refrence: 
http://stackoverflow.com/questions/35295260/adfs-openid-connect-email-claim-and-external-adfs