MAC OS X VPN client / Certificates / Cisco ASA series - osx-lion

I spent a lot of time surfing the web for the solution, but alas, so I finally concluded that this might be an interesting topic to discover.
Here's the task:
1. I need to establish VPN connection from MAC OS X (preferrably built in IPSec client) to remote Cisco ASA 5500.
2. What I have: two certificates, one for VPN connection cyphering, one for remote desktop login. Both of them stored on eToken.
The problem is in setting up the connection:
On the cisco official website there is a remark about supported vpn clients and there mac os x built in IPSec client seems to be suitable. Moreover, for ASA 5500 it's suitable both in "l2tp over ipsec" and "Cisco IPSec" modes.
Now, let's try to establish "Cisco IPSec" (settings>network>add connection). I have host address, account name and password, and I'm sure it's correct because I checked it in Win7.
The most interesting thing is in "Authentication settings": here, I supposed to choose a certificate, but my Keychain reports, that there are no suitable certificates in my Keychain.
And the reason for that might be in "type" of certificates. All the certificates I have are identified by OS X as a user certificates so it cannot be used to authorize the machine (by the way, is it right?).
Okay, if we try the l2tp over IPSec there is the same problem: I can even choose a user cerificate from eToken, but I still have no machine cert.
This is how it usually looks like in Windows:
Run Cisco VPN Client
Set up Host address, than just choose certificate (which is allowed to be choosed somehow :) )
Tap connect, enter pin for eToken and you are connected
So how to set up a connection if:
1. eToken is quite visible with its certs even for native IPsec client.
2. There is a cisco asa 5500 on other end.
OR I would be glad for a hint or a link to where I can find any description about cisco vpn features...
System: OS X Lion 10.7.4, eToken SafeNet Authentication Client 8.0.
If someone know a decision for different clients - it will be nice to see it here.
Thanks beforehand!

The Certificate Authority is managed through OpenSSL and this currently resides on server 497398 (appdr.Company.com).
The CA directory structure is in /etc/pki/CA/
The OpenSSL config file is located in /etc/pki/tls/openssl.cnf
The most important configuration entry in the openssl.cnf file is the line:
subjectAltName = DNS:primary-vpn.Company.com,DNS:backup-vpn.Company.com
This line REQUIRES spaces around the = sign.
If the customer should ever choose to add another firewall device, this line will need to be updated with that FQDN in another DNS: entry and all keys will have to be re-created and re-issued to the users.
The firewalls on the customer's account in DFW and ORD are setup to authenticate via two-stage authentication utilizing certificates as well as username/passwords.
We are using certificates that we've generated on the CA and distributed to the clients. Each firewall also requires it's own certificate in PFX format as well as a copy of the PEM formatted CA certificate. The PFX certs for the firewall devices MUST NOT include the CA cert. The CA cert has to be separately imported onto the firewall in PEM format! This CA cert becomes a Trust Point on the firewall.
The firewalls also include basic username/password authentication which is set on the device itself.
The firewall certificate key passwords are documented with the devices themselves in the Password Notes.
The clients are required to connect to the DNS name for each firewall and it must (as of 05/31/2013) be either primary-vpn.Company.com or backup-vpn.Company.com. Connecting via IP address is not supported as the certificates do not include the subjectAltName for the IP addresses. This is to support any future IP changes without having to re-key all the clients and devices.
Each user requires a separate key and certificate to be generated using openssl and the CA key. The CA key password is documented under the Device 497398 (appdr) in Password Notes.
You will need the CA key password for the certificate creation process below (openssl ca ...)
How to add new users...
On ca-server:
Change to the OpenSSL CA directory
cd /etc/pki/CA
Generate Key
openssl genrsa 2048 -out > username.Companyvpn.key
Generate CSR
openssl req -new -key username.Companyvpn.key -out username.Companyvpn.csr
(OU = username)
(Common Name = username)
(No password)
Generate Cert
openssl ca -policy policy_anything -out username.Companyvpn.crt -infiles username.Companyvpn.csr
(Yes to sign certificate)
Generate new random password (12 characters)
echo </dev/urandom tr -dc 'a-zA-Z0-9'| head -c12
Make PFX cert/key archive
openssl pkcs12 -export -out username.Companyvpn.pfx -inkey username.Companyvpn.key -in username.Companyvpn.crt -certfile /etc/pki/CA/certs/CompanyCA.crt
(Enter random password you just generated)
Verify the certificate with this command
openssl x509 -in username.Companyvpn.crt -text -noout
Look for the expiration date, it should be one year.
Also look for the line:
X509v3 Subject Alternative Name
If you do not see the Subject Alternative Name line -- STOP -- something may be wrong with the openssl.cnf file!!
Contact a higher-level administrator for assistance
Distribute the new PFX file by attaching it to the customer ticket and give them the password.
How to create a device certificate/key...
On ca-server:
Change to OpenSSL CA directory
cd /etc/pki/CA
Generate key for FW device itself
openssl genrsa 1024 > backup-vpn.Company.com.key
Generate CSR for FW device itself
openssl req -new -key backup-vpn.Company.com.key -out backup-vpn.Company.com.csr
(OU is Kimbia Certificate)
(Common name backup-vpn.Company.com)
(No password)
Generate certificate from CSR for FW device
openssl ca -days 3650 -in backup-vpn.Company.com.csr -out backup-vpn.Company.com.crt
Make PFX for FW device (no bundled CA cert)
openssl pkcs12 -export -out backup-vpn.Company.com.pfx -inkey backup-vpn.Company.com.key -in backup-vpn.Company.com.crt
(Use 'rack' for export passphrase or generate a random one)
Base64 encode PFX archive for NetSec to include on ASA as the Cisco device requires this
openssl base64 -in backup-vpn.Company.com.pfx -out backup-vpn.Company.com.pfx.b64
Distribute Base64-encoded PFX archive to NetSec team
Distribute PEM-encoded /etc/pki/CA/certs/CompanyCA.crt to NetSec team
Heaven forbid, if you should have to regenerate the CA certificate and key, here is the process...
Change directory to CA
cd /etc/pki/CA
Generate the key
openssl genrsa -out /etc/pki/CA/private/CompanyCA.key -des3 2048
Generate the certificate
openssl req -new -x509 -key /etc/pki/CA/private/CompanyCA.key -days 3650 > /etc/pki/CA/certs/CompanyCA.crt
You must now re-generate all device keys and certs, reconfigure all devices, and the re-generate all user keys and certs according to the instructions above.
We have set the expiration for the current CA/Device sets for 2023 to try and avoid having to do it all over again.
To revoke a particular certificate and disable a user...
On ca-server:
Change directory to CA
cd /etc/pki/CA
Revoke cert
openssl ca -revoke username.Companyvpn.crt
Have NetSec remove the username and tunnel group entries from the firewall.
Here is the current /etc/pki/tls/openssl.cnf as of 05/31/2013
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#
# This definition stops the following lines choking if HOME isn't
# defined.
HOME = .
RANDFILE = $ENV::HOME/.rnd
# Extra OBJECT IDENTIFIER info:
#oid_file = $ENV::HOME/.oid
oid_section = new_oids
# To use this configuration file with the "-extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
#extensions = v3_req,v3_ca
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)
[ new_oids ]
# We can add new OIDs in here for use by 'ca', 'req' and 'ts'.
# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6
# Policies used by the TSA examples.
tsa_policy1 = 1.2.3.4.1
tsa_policy2 = 1.2.3.4.5.6
tsa_policy3 = 1.2.3.4.5.7
####################################################################
[ ca ]
default_ca = CA_default # The default ca section
####################################################################
[ CA_default ]
dir = /etc/pki/CA # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
#unique_subject = no # Set to 'no' to allow creation of
# several ctificates with same subject.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $certs/CompanyCA.crt # The CA certificate
serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber # the current crl number
# must be commented out to leave a V1 CRL
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/CompanyCA.key # The private key
RANDFILE = $dir/private/.rand # private random number file
x509_extensions = usr_cert # The extentions to add to the cert
# Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt = ca_default # Subject Name options
cert_opt = ca_default # Certificate field options
# Extension copying option: use with caution.
# copy_extensions = copy
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crlnumber must also be commented out to leave a V1 CRL.
# crl_extensions = crl_ext
default_days = 365 # how long to certify for
default_crl_days= 30 # how long before next CRL
default_md = default # use public key default MD
preserve = no # keep passed DN ordering
# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy = policy_match
# For the CA policy
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
# For the 'anything' policy
# At this point in time, you must list all acceptable 'object'
# types.
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
####################################################################
[ req ]
default_bits = 2048
default_md = sha1
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
# Passwords for private keys if not present they will be prompted for
# input_password = secret
# output_password = secret
# This sets a mask for permitted string types. There are several options.
# default: PrintableString, T61String, BMPString.
# pkix : PrintableString, BMPString (PKIX recommendation before 2004)
# utf8only: only UTF8Strings (PKIX recommendation after 2004).
# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
# MASK:XXXX a literal mask value.
# WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings.
string_mask = utf8only
req_extensions = v3_req # The extensions to add to a certificate request
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = US
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Texas
localityName = Locality Name (eg, city)
localityName_default = AmericanCity
0.organizationName = Organization Name (eg, company)
0.organizationName_default = Software Company Inc
# we can do this but it is not needed normally :-)
#1.organizationName = Second Organization Name (eg, company)
#1.organizationName_default = World Wide Web Pty Ltd
organizationalUnitName = Organizational Unit Name (eg, section)
#organizationalUnitName_default = Software Company Certificate
commonName = Common Name (eg, your name or your server\'s hostname)
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 64
# SET-ex3 = SET extension number 3
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName = An optional company name
[ usr_cert ]
# These extensions are added when 'ca' signs a request.
# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.
basicConstraints=CA:FALSE
# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.
# This is OK for an SSL server.
# nsCertType = server
# For an object signing certificate this would be used.
# nsCertType = objsign
# For normal client use this is typical
# nsCertType = client, email
# and for everything including object signing:
# nsCertType = client, email, objsign
# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# This will be displayed in Netscape's comment listbox.
nsComment = "OpenSSL Generated Certificate"
# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move
# Copy subject details
# issuerAltName=issuer:copy
#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName
# This is required for TSA certificates.
# extendedKeyUsage = critical,timeStamping
subjectAltName = DNS:primary-vpn.Company.com,DNS:backup-vpn.Company.com
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
#subjectAltName = DNS:primary-vpn.Company.com
#subjectAltName = IP:122.123.321.221
#subjectAltName=IP:221.321.123.122,DNS:backup-vpn.Company.com
#subjectAltName=IP:122.123.321.221,DNS:primary-vpn.Company.com
# Changing from IP+DNS to just DNS to mitigate future IP change issues
# Added quotes 130530-07939
[ v3_ca ]
# Extensions for a typical CA
# PKIX recommendation.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
# This is what PKIX recommends but some broken software chokes on critical
# extensions.
#basicConstraints = critical,CA:true
# So we do this instead.
basicConstraints = CA:true
# Key usage: this is typical for a CA certificate. However since it will
# prevent it being used as an test self-signed certificate it is best
# left out by default.
# keyUsage = cRLSign, keyCertSign
# Some might want this also
# nsCertType = sslCA, emailCA
# Include email address in subject alt name: another PKIX recommendation
# subjectAltName=email:copy
# Copy issuer details
# issuerAltName=issuer:copy
# DER hex encoding of an extension: beware experts only!
# obj=DER:02:03
# Where 'obj' is a standard or added object
# You can even override a supported extension:
# basicConstraints= critical, DER:30:03:01:01:FF
subjectAltName = DNS:primary-vpn.Company.com,DNS:backup-vpn.Company.com
[ crl_ext ]
# CRL extensions.
# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL.
# issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always
[ proxy_cert_ext ]
# These extensions should be added when creating a proxy certificate
# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.
basicConstraints=CA:FALSE
# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.
# This is OK for an SSL server.
# nsCertType = server
# For an object signing certificate this would be used.
# nsCertType = objsign
# For normal client use this is typical
# nsCertType = client, email
# and for everything including object signing:
# nsCertType = client, email, objsign
# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# This will be displayed in Netscape's comment listbox.
nsComment = "OpenSSL Generated Certificate"
# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
###################################################
###################################################
###Change the subjectAltName per DC####
# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# MOVED THIS UNDER [ v3_req ] above
##
#subjectAltName=IP:221.321.123.122,DNS:backup-vpn.Company.com
#subjectAltName=IP:122.123.321.221,DNS:primary-vpn.Company.com
# Changing from IP+DNS to just DNS to mitigate future IP change issues
#subjectAltName="DNS:primary-vpn.Company.com"
#####################################################
#####################################################
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move
# Copy subject details
# issuerAltName=issuer:copy
#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName
# This really needs to be in place for it to be a proxy certificate.
proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo
####################################################################
[ tsa ]
default_tsa = tsa_config1 # the default TSA section
[ tsa_config1 ]
# These are used by the TSA reply generation only.
dir = ./demoCA # TSA root directory
serial = $dir/tsaserial # The current serial number (mandatory)
crypto_device = builtin # OpenSSL engine to use for signing
signer_cert = $dir/tsacert.pem # The TSA signing certificate
# (optional)
certs = $dir/cacert.pem # Certificate chain to include in reply
# (optional)
signer_key = $dir/private/tsakey.pem # The TSA private key (optional)
default_policy = tsa_policy1 # Policy if request did not specify it
# (optional)
other_policies = tsa_policy2, tsa_policy3 # acceptable policies (optional)
digests = md5, sha1 # Acceptable message digests (mandatory)
accuracy = secs:1, millisecs:500, microsecs:100 # (optional)
clock_precision_digits = 0 # number of digits after dot. (optional)
ordering = yes # Is ordering defined for timestamps?
# (optional, default: no)
tsa_name = yes # Must the TSA name be included in the reply?
# (optional, default: no)
ess_cert_id_chain = no # Must the ESS cert id chain be included?
# (optional, default: no)

Related

Why does chrome errors with NET::ERR_CERT_COMMON_NAME_INVALID on admin.localhost with SAN and CN set to *.localhost

I want to create a http/2 server with admin panel attached as subdomain.
I created certificate with CN=*.localhost and subjectAltName = *.localhost and localhost
# server.scr.cnf
[req]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
[dn]
CN = *.localhost
OU=Random
C=US
ST=RandomState
L=RandomCity
O=RandomOrganization
emailAddress=hello#example.com
# v3.ext
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = #alt_names
[alt_names]
DNS.1 = *.localhost
DNS.2 = localhost
Then i went to chrome (tested on stable (88.0.4324.146) & canary (90.0.4410.2) versions, no differences) and saw these results:
https://localhost:7000 works properly, no errors.
https://admin.localhost:7000 doesn't work, but i excepted that certificate won't give any errors (no errors on server side, proceeding to admin.localhost:7000 gives appropriate page) -
I've tried to change CN to localhost, tried to add more wildcards such as *.*.localhost, (and etc.), nothing of these worked.
The only way to fix the problem i see is to add admin.localhost to alt_names, but it's a burden for me, because of need to add each sub to alt_names, so i don't appreciate that solution and i want to understand why didn't the *.localhost work.

Create certificate and CSR using Windows PowerShell/.Net without using external programs or libraries

I would like to create a Private Key and a CSR, submit the CSR to a Certificate Authority, retrieve the certificate once issued, and have the Private Key and Certificate as separate PEM files suitable for use in non-Microsoft applications (they are generally web servers). I'd like to avoid using Java Keytool or OpenSSL to generate keys and certificate signing requests in Windows PowerShell on Windows Server 2016. The CSRs will be submitted to a Microsoft Active Directory Certificate Services.
OpenSSL and Java are not (and won't be) installed on the computers requiring certificates. As the certificates are for non-Microsoft applications, I also want to avoid using the Certificate Store on the computers. I don't mind using "certreq" to actually submit the completed CSR and retrieve the resulting certificate once approved.
I have some code, based on C# Export Private/Public RSA key from RSACryptoServiceProvider to PEM string, which will extract the private key from an X509Certificate2. So far, as an experiment, I have used this successfully with a PKCS12 keystore (where the key and CSR were created with Keytool).
Inspired by Automate the process of creating a private key, a CSR and a final Signed Certificate in .NET Core I knocked together the following, but ran out of inspiration, and didn't really know what I was doing. How do I complete the process of submitting the CSR to the CA (or outputting the CSR as a file for using with certreq)?
[int]$KeyLength = 2048
$ComputerName = "jon"
$Domain = "domain.local"
[string]$DistinguishedName = "CN=$($ComputerName).$($Domain),OU=Unit,O=Org,C=GB"
$HashAlgo = [System.Security.Cryptography.HashAlgorithmName]::SHA256
$RSASigPadding = [System.Security.Cryptography.RSASignaturePadding]::Pkcs1
$RSAKey = [System.Security.Cryptography.RSA]::Create($KeyLength)
$Certificate = [System.Security.Cryptography.X509Certificates.CertificateRequest]::new($DistinguishedName,$RSAKey,$HashAlgo,$RSASigPadding)
# Add Basic Constraints
$BasicConstraints = [System.Security.Cryptography.X509Certificates.X509BasicConstraintsExtension]::new($false,$false,0,$false)
$BCExtension = [System.Security.Cryptography.X509Certificates.X509Extension]::new($BasicConstraints,$false)
$Certificate.CertificateExtensions.Add($BCExtension)
# Add Subject Key Identifier extension
$SubjectKeyIdentifier = [System.Security.Cryptography.X509Certificates.X509SubjectKeyIdentifierExtension]::new($Certificate.PublicKey,$false)
$SKIExtension = [System.Security.Cryptography.X509Certificates.X509Extension]::new($SubjectKeyIdentifier,$false)
$Certificate.CertificateExtensions.Add($SKIExtension)
# Add Key Usage
$KeyUsageFlags = [System.Security.Cryptography.X509Certificates.X509KeyUsageFlags]::DigitalSignature -bor [System.Security.Cryptography.X509Certificates.X509KeyUsageFlags]::KeyEncipherment
$KeyUsage = [System.Security.Cryptography.X509Certificates.X509KeyUsageExtension]::new($KeyUsageFlags,$true)
$KUExtension = [System.Security.Cryptography.X509Certificates.X509Extension]::new($KeyUsage,$true)
$Certificate.CertificateExtensions.Add($KUExtension)
# Add EKU
$ServerAuthentication = [System.Security.Cryptography.Oid]::New("Server Authentication")
$EKUOidCollection = [System.Security.Cryptography.OidCollection]::new()
$EKUOidCollection.Add($ServerAuthentication) | out-null # this outputs 0
$EnhancedKeyUsage = [System.Security.Cryptography.X509Certificates.X509EnhancedKeyUsageExtension]::new($EKUOidCollection,$false)
$EKUExtension = [System.Security.Cryptography.X509Certificates.X509Extension]::new($EnhancedKeyUsage,$false)
$Certificate.CertificateExtensions.Add($EKUExtension)
# Add SAN
$SubjectAlternateNameBuilder = [System.Security.Cryptography.X509Certificates.SubjectAlternativeNameBuilder]::new()
$SubjectAlternateNameBuilder.AddDnsName("$($ComputerName).$($Domain)")
$Certificate.CertificateExtensions.Add($SubjectAlternateNameBuilder.Build())

Can SSL cert be used to digitally sign files?

I want to ask a thing about digital signing I am not very sure.
Instead of creating a self signed certificate to use to sign some (PDF) files, I wanted to take my SSL cert which have my data already verified.
But the question is: Can a SSL cert be used to digital sign files or is it incompatible in some manner?
EDIT: To clarify, this question is not about how to sign PDFs, is only about if a SSL cert can be used (or converted in any way) to sign files.
To support digital signing certificate must have digitalSignature option in it's keyUsage field (and codeSigning option in it's extendedKeyUsage field if your want to sign programs with it).
Signing may be done with existing tools or manually (java example, you are not asking for it, but this code snippet might be useful anyway):
byte[] bytesToSign = loadMyData();
KeyStore ks = KeyStore.getInstance("pkcs12", "SunJSSE");
ks.load(new FileInputStream("cert.p12"), "passwd1".toCharArray());
PrivateKey privateKey = (PrivateKey) ks.getKey("myalias", "passwd2".toCharArray());
Signature sig = Signature.getInstance("SHA1withRSA", ks.getProvider());
sig.initSign(privateKey);
sig.update(bytesToSign);
byte[] signature = sig.sign();
To make your own not self-signed certificate with openssl see this SO answer.
Also curious about signing PDF's - aren't separate hash sums of these files enough in your case?
edit: if you want any sign, not exactly X.509 sign by existing tools, you can extract RSA key from your cert and do signing without bothering about keyUsage field.
At the core, the certificate is just a normal RSA public key that's been signed by several authorities.
So yes, definitely possible.
Though I don't know of any easy-to-use widespread tools for the end-user for this.
Yes, you can sign and verify the signature of files using SSL certificates
Here is an example:
SSLCERT='/XXXX/ssl/certs/fqdn.pem'
SSLKEY='/XXXX/ssl/private_keys/fqdn.pem'
# You might not need to specify a CA
CACERTFILE='/XXXX/ssl/certs/ca.pem'
# File to sign
FILE='YYYYYYY'
# Signs, needs ${SSLKEY} and ${FILE}
openssl dgst -sha512 -sign ${SSLKEY} -out ${FILE}.sha512 ${FILE}
# Then transfer the following files to another server:
# - ${CACERTFILE}
# - ${SSLCERT}
# - ${FILE}
# - ${FILE}.sha512
# Check the certificate is valid
openssl verify -verbose -CAfile ${CACERTFILE} ${SSLCERT}
# Extract the pub key from the cert
openssl x509 -in ${SSLCERT} -pubkey -noout > ${SSLCERT}.pub
# Check the signature
openssl dgst -sha512 -verify ${SSLCERT}.pub -signature ${FILE}.sha512 ${FILE}

add or create 'Subject Alternative Name' field to self-signed certificate using makecert

How can I create a certificate using makecert with a 'Subject Alternative Name' field ?
You can add some fields eg, 'Enhanced Key Usage' with the -eku option and I've tried the -san option but makecert doesn't like it.
This is a self-signed certificate so any method that uses IIS to create something to send off to a CA won't be appropriate.
An even easier way is to use the New-SelfSignedCertificate PowerShell commandlet, which includes a SAN by default. In a single command you can create the certificate and add it to the store.
New-SelfSignedCertificate -DnsName localhost -CertStoreLocation cert:\LocalMachine\My
Note that you need to run PowerShell as an administrator.
Makecert doesn't appear to support SANs so I created a certificate with SANs for use with IIS using OpenSSL. Check out my blog post about it:
IIS 7 provides some easy to use wizards to create SSL certificates,
however not very powerful ones. What I needed to do was to create SSL
certificates that included a x.509 V3 extension, namely subject
alternative names, a.k.a SANs. What SANs do is allow the website
certificate to validate incoming requests by more than one URL domain
name. This is really important when the web server is running web
services such as WCF services and when other web services connect to
them over SSL connections as with service oriented architectures.
Unless special code is added to the web services to override the
default SSL validation handler routines, the common name (CN) of the
certificate MUST match the incoming request URL domain. So if the
request was made using an FQDN, the certificate must have the FQDN as
a CN or a SAN, a IP address or just a hostname will cause an SSL
validation error and the connection will fail.
SANs to the rescue… SANs support, among other things, DNS names and IP
addresses. So by creating the certificate with SANs of the server FQDN
and IP address, it increases the ways that other web services can
connect.
There are a number of tools that can generate certificates:
makecert.exe, keytool.exe (java), selfssl.exe and openssl.exe. In
addition, starting with Windows Vista and Server 2008 Microsoft added
the CertEnroll API which can also create certificates programmatically
either through COM interfaces.
OpenSSL ended up doing exactly what I needed it to do. The process was
fairly straight forward.
Construct an OpenSSL config file.
[req] distinguished_name = req_distinguished_name x509_extensions =
v3_req prompt = no [req_distinguished_name] C = US ST = VA L =
Somewhere O = MyOrg OU = MyOU CN = MyServerName [v3_req] keyUsage =
keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth
subjectAltName = #alt_names [alt_names] DNS.1 = MyServerName DNS.2 =
10.0.1.34 IP.1 = 10.0.1.34 IP.2 = 192.167.20.1
Create x509 request with OpenSSL
openssl.exe req -x509 -nodes -days 730 -newkey rsa:2048 -keyout
C:\cert.pem -out C:\cert.pem -config C:\PathToConfigFileAbove.txt
Create a PFX containing the keypair
openssl.exe pkcs12 -export -out C:\cert.pfx -in C:\cert.pem -name "My
Cert" -passout pass:mypassword
Import the PFX into IIS using the import link in the server
certificates area.
Bind the certificate to the IIS websites.
And viola, we know have a SSL certificate for IIS with SANs so we can
connect using multiple domain names without certificate validation
errors.
Source: Creating certificates with SANs using OpenSSL by Andy Arismeti, Thursday, September 1, 2011
Update
The certificate generated using the below makecert method does not work reliably in all browsers, because it does not actually generate a "Subject Alternative Name".
If you examine the certificate you will see that it does not actually have a Subject Alternative Name field, but instead specifies multiple CN in the Subject field.
E.g.
Subject:
CN = blah.foo.corp
CN = blah
Whereas a real "SAN" cert would have something like:
Subject Alternative Name:
DNS Name=blah.foo.corp
DNS Name=blah
To understand the differences and history between the "Subject" field with "Common Name" and the "Subject Alternative Name" field, I recommend reading The (soon to be) not-so Common Name.
So it appears that makecert cannot be used to generate a true "SAN" cert, and you will need to use other tools, such as openssl.
Original Answer:
At least with the version of makecert that comes with Visual Studio 2012, you can specify multiple subjects, simply by specifying a comma separated list -n "CN=domain1, CN=domain2"
E.g. (from the technet blog Makecert.exe SAN and Wildcard certificate)
makecert -r -pe -n "CN=*.fabrikam.com, CN=*.contoso.com" -b 01/01/2010 -e 01/01/2100 -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.3,1.3.6.1.5.5.7.3.4 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 -len 2048

Setting Key Usage attributes with Makecert

Is it possible to set Key Usage attributes using makecert, or any other tool I can use to generate my own test certificates?
The reason I'm interested is that certificates used for BizTalk Server AS2 transport require a key usage of Digital Signature for signing and Data Encipherment or Key Encipherment for encryption/decryption, and I want to play around with this feature.
I see how to set enhanced key usage attributes with makecert, but not key usage.
While you cannot make a self-signed cert and set the Enhanced Key Usage parameters using makecert I thought I'd save everyone the trouble of trying to use go down the path of using OpenSSL to generate a cert on Windows. Instead, you can use certreq (which is available if you already have makecert) and fashion your own request to set the required parameters.
For example, this sets up a cert with an EKU of Document Encryption (1.3.6.1.4.1.311.80.1) and key usages of Key Encipherment and Data Encipherment.
Create a new file, MyCert.inf:
[Version]
Signature = "$Windows NT$"
[Strings]
szOID_ENHANCED_KEY_USAGE = "2.5.29.37"
szOID_DOCUMENT_ENCRYPTION = "1.3.6.1.4.1.311.80.1"
[NewRequest]
Subject = "cn=me#example.com"
MachineKeySet = false
KeyLength = 2048
KeySpec = AT_KEYEXCHANGE
HashAlgorithm = Sha1
Exportable = true
RequestType = Cert
KeyUsage = "CERT_KEY_ENCIPHERMENT_KEY_USAGE | CERT_DATA_ENCIPHERMENT_KEY_USAGE"
ValidityPeriod = "Years"
ValidityPeriodUnits = "1000"
[Extensions]
%szOID_ENHANCED_KEY_USAGE% = "{text}%szOID_DOCUMENT_ENCRYPTION%"
Just set the Subject to whatever you need.
Then run:
certreq -new MyCert.inf MyCert.cer
This will generate the public key (X509 cert) and install it to your Current User personal store on the machine. You can export it from there if you want.
I used this to generate a certificate for encrypting PowerShell DSC, for testing.
For more details: https://technet.microsoft.com/en-us/library/dn296456.aspx#BKMK_New
Digital Signature,Data Encipherment and Key Encipherment can be add by using the PowerShell Cmdlet New-SelfSignedCertificate. One of the New-SelfSignedCertificate Parameters is KeyUsagewhere you can add DigitalSignature, DataEncipherment and KeyEncipherment.
New-SelfSignedCertificate is described on technet (https://technet.microsoft.com/library/hh848633)
Sample:
New-SelfSignedCertificate -Type Custom -Subject "CN=sample.com" -KeyUsage DataEncipherment, KeyEncipherment, DigitalSignature -TextExtension #("2.5.29.37={text}1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.1") -CertStoreLocation "Cert:\CurrentUser\My"
The sample covers client authentication and server authentication and creates the certificate at the current user store under my.
MakeCert doesn't let you specify key usage, only extended key usage. I think you need a CA to create a broader certificate.
You can setup your own CA with ubuntu server. https://www.digitalocean.com/community/tutorials/how-to-create-a-ssl-certificate-on-apache-for-ubuntu-14-04
You can use the -eku option to specify the key usage to your certificate.
See details here:
http://msdn.microsoft.com/en-us/library/aa386968(VS.85).aspx