I am trying to validate a certificate I got from Apple with their own intermediate and root certificate. This is what I do and the answer I get:
c:\dev\OpenSSL-Win64\bin>openssl.exe verify -CAfile k:\MDM\AppleIncRootCertificate.pem k:\MDM\AppleWWDRCA.pem k:\MDM\mdm_public.pem
k:\MDM\AppleWWDRCA.pem: OK
k:\MDM\mdm_public.pem: UID = NQLH5GG9T6, CN = MDM Vendor: E A/S, OU = E A/S, O = E A/S, C = DK
error 20 at 0 depth lookup:unable to get local issuer certificate
Does anyone have an explanation or solution to this?
The problem is the way I use openssl verify which is incorrect. The certificate chain needs to be concatenated in a file (AppleIncRootCertificate.pem and AppleWWDRCA.pem) and the correct use is like this:
openssl.exe verify -CAfile k:\mdm\cert_chain k:\MDM\mdm_public.pem
Which results in:
k:\MDM\mdm_public.pem: OK
Related
I am using a powershell script to create Certificate Signing Request (CSR) using certreq. I need the private key in a file but the script is not generating that. I tried looking the documentation of certreq and other resources but found nothing. In INF setting I am setting Exportable = TRUE. here is the setting
$settingsInf = "
[Version]
Signature=`"`$Windows NT`$
[NewRequest]
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
RequestType = PKCS10
ProviderName = `"Microsoft RSA SChannel Cryptographic Provider`"
ProviderType = 12
HashAlgorithm = sha256
;Variables
Subject = `"CN={{CN}},CN={{CN2}},O={{O}},DC={{DC}},DC={{DC2}}`"
[Extensions]
{{SAN}}
Another solution I tried is to use openssl to get private key and CSR. In this solution I am getting both private key and CSR but when I submit the CSR to CA then it throws following error
"message" : "Invalid Subject DN. The requested Subject DN is not compatible with the issuing CA.",
I am using openssl as follows
$subject = "`"/CN=$cn/CN=$cn2/O=$o/DC=$dc/DC=$dc2'"
openssl req -new -key $privateKeyPath -rand $randPath -subj $subject -out $csrPath
The Certificate Authority DN is as follows
"issuer_dn" : "CN=usa,O=SE,DC=abc,DC=com",
any suggestion to either get private key using certreq or why CA is throwing error when using openssl. Thanks
I found the solution. may be it will help someone else.
It appears that some CA require subject in a particular order which is not documented (Super Annoying).
The CA I was connected to require $subject in following way
$subject = "`"/DC=$dc2/DC=$dc/O=$o/CN=$cn2/CN=$cn'"
using subject like this in generating CSR is accepted by CA.
Perl newbie here.
I need to chain an intermediate CA x509 certificate to my client certificate.
Net::SSLeay::set_cert_and_key($ctx, $crt, $key);
my $bio = Net::SSLeay::BIO_new_file("subca.crt", 'r');
my $x509 = Net::SSLeay::PEM_read_bio_X509($bio);
Net::SSLeay::CTX_add_extra_chain_cert($ctx, $x509)
and die_if_ssl_error("CTX_add_extra_chain_cert"); # It dies here.
The certificate is in pem format. Can anyone help?
Edit: I have found that the call to "Net::SSLeay::PEM_read_bio_X509()" returns 0, which is an error condition.
This does exactly what I was looking for:
Net::SSLeay::CTX_use_RSAPrivateKey_file($ctx, $key, &Net::SSLeay::FILETYPE_PEM)
and die_if_ssl_error("private key");
Net::SSLeay::CTX_use_certificate_chain_file($ctx, $crt)
and die_if_ssl_error("CTX_use_certificate_chain_file");
$crt contains 2 certificates, first the client certificate, followed by the intermediate one.
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)
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}
On running:
openssl ca -in ${ALIAS}.csr -out user-cert.pem -keyfile cacert-private.pem -cert cacert.pem -passin pass:$PASSWD -config ${CONFIG}
I get:
The stateOrProvinceName field needed to be the same in the
CA certificate (Gloucestershire) and the request (Gloucestershire)
I've read the error a few times and I'm fairly sure the field is the same value in each case. I have found references to similar problems being caused by different encodings but I don't know how I should be specifying that and where.
This is the ${ALIAS}.csr:
-----BEGIN NEW CERTIFICATE REQUEST-----
MIICxzCCAa8CAQAwgYExCzAJBgNVBAYTAkdCMRgwFgYDVQQIEw9HbG91Y2VzdGVyc2hpcmUxEzAR
BgNVBAcTCkNoZWx0ZW5oYW0xHzAdBgNVBAoTFldhbnNkeWtlIEhvdXNlIExpbWl0ZWQxDjAMBgNV
BAsTBUZpemlvMRIwEAYDVQQDEwlsb2NhbGhvc3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDWvivt1JHiuaNeadOQJtxynQ4sSAR/peWgKd8g9UQgNM+H9QW4NlRE81+g63BdRqZT5YMm
J4K3upovQNlDRklevslgEYoTdQM4yBKV676Q4XDbM7Vk+rt04sqL5IgdsAUXODfMJvu81t3tOjFc
OGO7S+B+LEJ1+8qshLbuK2gBigfgcZtlbNgW6fCGik8ZsrKWl8W+NFbw1seS01INAipwCBasxaaj
/lINwWQVbQIG09+vEdwuHmmq5VIKlJqFcYNUTFBVojoJLfzyStZR2PfFUxp7R+t2YmVj6a48B7NA
lODnIlQDkAprECNMpCZoSP1QjrZgW1BgaVbT5OaWlVsPAgMBAAGgADANBgkqhkiG9w0BAQUFAAOC
AQEAvalFyJOgzmd1jcFlS5YoqiNgX1bm9nZ0/cFgj6cGL7R0Gqc9wu5QPakWRxa9c2UcI0m7p1lp
cygDvQTY23LEBhVcruymIGQG5DhDpXHeaBCbV3OWO6xowAjh+riQjvTNeVSXtP3jUNs5DaId0z+A
GXeb7dR96jhyj+soNYENoQseQLqLdAW4p0jdK1BraMJTc0ber0FBx1nOUXOEoTIJL9kL9cUWaCp3
7uYkonIPtVCCfS8KcgXxUsNMC41q/SkKDVB23PeCjnWgcyXxnSpx8n+AK7fwMgh+4TcZ5usmVujR
MNqk84hZpw8h1FIcmqRaWtaPWyv3EX8JH5LTnDe3eQ==
-----END NEW CERTIFICATE REQUEST-----
And cacert.pem:
-----BEGIN CERTIFICATE-----
MIIDQDCCAqmgAwIBAgIJAPj9mvMDl1K/MA0GCSqGSIb3DQEBBQUAMIG4MQswCQYD
VQQGEwJHQjEYMBYGA1UECAwPR2xvdWNlc3RlcnNoaXJlMRMwEQYDVQQHDApDaGVs
dGVuaGFtMR8wHQYDVQQKDBZXYW5zZHlrZSBIb3VzZSBMaW1pdGVkMQ4wDAYDVQQL
DAVGaXppbzESMBAGA1UEAwwJbG9jYWxob3N0MTUwMwYJKoZIhvcNAQkBFiZyaWNo
YXJkLm1pZHdpbnRlckB3YW5zZHlrZS1ob3VzZS5jby51azAeFw0xMTA4MDcyMTU4
NDBaFw0yMTA4MDQyMTU4NDBaMIG4MQswCQYDVQQGEwJHQjEYMBYGA1UECAwPR2xv
dWNlc3RlcnNoaXJlMRMwEQYDVQQHDApDaGVsdGVuaGFtMR8wHQYDVQQKDBZXYW5z
ZHlrZSBIb3VzZSBMaW1pdGVkMQ4wDAYDVQQLDAVGaXppbzESMBAGA1UEAwwJbG9j
YWxob3N0MTUwMwYJKoZIhvcNAQkBFiZyaWNoYXJkLm1pZHdpbnRlckB3YW5zZHlr
ZS1ob3VzZS5jby51azCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA03Y4hYdd
at3e3AB98s+E5wlxrvRL8RhJtRac0Jt0gXQy12ZYziFm3gryx0IG02srXluM+V3/
BPRRCLsnEnltfoi/fE0wM9MT0V1Ao9EXQ5t1E2rOzdoXUUdvovd6qvwG2L/DHCdL
kKjhokVR9TkFW/AWctBdWkb9qfFFTpDY4i0CAwEAAaNQME4wHQYDVR0OBBYEFHbG
d3+Lzax90slk65y1BYDgZ897MB8GA1UdIwQYMBaAFHbGd3+Lzax90slk65y1BYDg
Z897MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEArZ2yfTGJK3R+jRwP
FjaonDy1NVOt9tgjHfyh9YNQfyFSC7R987wFPcyydEqh8xg/Lb3WGwseDuzCBusw
jmVIqiUYBClHzkF3jG1766ltdlVVTOavVQgQMRBGMvpHVxcMH2RUNUyWH0XW+DH2
/uuRRpu4vX5sfEW75uEfORB9Mrg=
-----END CERTIFICATE-----
Any ideas? Thanks in advance.
You can also set the attributes as optional:
# For the CA policy
[policy_match]
countryName= optional
stateOrProvinceName= optional
organizationName= optional
organizationalUnitName= optional
commonName= supplied
emailAddress= optional
I have also run into this problem. Thanks to the replies above (mainly Francois), I discovered the source of the problem.
openssl is encoding using UTF8STRING and keytool (Java 6) is encoding with PRINTABLESTRING.
Worked around it by changing the openssl configuration so it matches keytool. In /usr/ssl/openssl.cnf change the "string_mask" setting to "pkix".
The previous posters already answered the question, but to make it easier, here is an example how to specify the encoding. Use the string_mask:
[ req ]
default_bits = 2048
default_md = rsa
prompt = no
string_mask = utf8only # <--------------
distinguished_name = req_distinguished_name
[ req_distinguished_name ]
countryName = GB
stateOrProvinceName = Gloucestershire
localityName = Cheltenham
organizationName = Wansdyke House Limited
organizationalUnitName = Fizio
commonName = localhost
As shown by :
openssl asn1parse -in req.csr
the request DN strings are encoded as PRINTABLESTRING.
openssl asn1parse -in cacert.pem
shows the CA DN strings are encoded as UTF8STRING.
For a quick'n dirty hack, I suggest you change the encoding of strings in your request by replacing the encoding type for PRINTABLESTRING (0x13) by the type for UTF8STRING (0x0c), using your favorite hex editor.
You will have to convert your request in DER before poking it.
The offset of bytes to change can be found with :
openssl asn1parse -in csr |grep PRINTABLESTRING |awk -F":" '{print $1}'
Then try to sign again.
I just ran into this problem. The root cause is a mismatch between the values of string_mask in the client's and the CA's openssl.cnf. The easy fix is to modify the client's value to match what the CA expects, then regenerate the CSR. The hard fix is to edit the CA's value and start a fresh CA.
Promoting mbrownnyc's comment to an answer, as it was useful to me and deserves more attention.
I believe /usr/ssl/openssl.cnf contains a policy called policy_anything that contains the above setup. You can use it by utilizing the policy argument as follows:
openssl ca -policy policy_anything -days 365 -out /root/ca/certs/out.pem -in certreq.csr