Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[openssl-users] Creating a Certificate with CA=TRUE

3,131 views
Skip to first unread message

Benjamin

unread,
Dec 19, 2014, 7:30:33 AM12/19/14
to
Hello everyone!
I am quite new to two things: this mailing list and making and working with certificates

I want to run a small owncloud on my raspberry pi and tried to make a crt which I can also use with my mobile devices. Here is the problem:
When i make a certificate either with this instruction:
http://wiki.ubuntuusers.de/CA
or this one:
https://www.prshanmu.com/2009/03/generating-ssl-certificates-with-x509v3-extensions.html

i have the problem that the cacert has "basicconstriants CA=TRUE" but when i make a cert by request i got a new cert (as far as i knew, that which i should use for my nginx webserver) which has CA=FALSE. This is no problem normally but my Android phone only accepts Certs with CA=TRUE and actually i don´t know how to make such a certificate…Of course, i could use the cacert itself but isn´t this insecure and inadequate?

Thanks, best Benjamin!

Ps Here is my openssl.cnf if it helps!



#
# 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
# (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        = ./demoCA        # 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    = $dir/cacert.pem     # 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/cakey.pem# 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        = 1024
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        = AU
countryName_min            = 2
countryName_max            = 2

stateOrProvinceName        = State or Province Name (full name)
stateOrProvinceName_default    = Some-State

localityName            = Locality Name (eg, city)

0.organizationName        = Organization Name (eg, company)
0.organizationName_default    = Internet Widgits Pty Ltd

# 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    =

commonName            = Common Name (e.g. server FQDN or YOUR name)
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:TRUE

# 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

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

[ 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, nonRepudiation, digitalSignature, keyEncipherment

# Some might want this also
# nsCertType = sslCA, emailCA

# Include email address in subject alt name: another PKIX recommendation
subjectAltName    = @alt_names
[alt_names]
DNS.1 = mindbase.no-ip.org
# 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

[ 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

# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=
# 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)

Jakob Bohm

unread,
Dec 19, 2014, 8:57:46 AM12/19/14
to
On 19/12/2014 13:13, Benjamin wrote:
> Hello everyone!
> I am quite new to two things: this mailing list and making and working
> with certificates
>
> I want to run a small owncloud on my raspberry pi and tried to make a
> crt which I can also use with my mobile devices. Here is the problem:
> When i make a certificate either with this instruction:
> http://wiki.ubuntuusers.de/CA
> or this one:
> https://www.prshanmu.com/2009/03/generating-ssl-certificates-with-x509v3-extensions.html
>
> i have the problem that the cacert has "basicconstriants CA=TRUE" but
> when i make a cert by request i got a new cert (as far as i knew, that
> which i should use for my nginx webserver) which has CA=FALSE. This is
> no problem normally but my Android phone only accepts Certs with
> CA=TRUE and actually i don´t know how to make such a certificate…Of
> course, i could use the cacert itself but isn´t this insecure and
> inadequate?
>
I very much doubt that Android only accepts certificates with CA=TRUE.

Unless of cause you are accidentally using an Android command to
install the "public certificate" of a CA, rather than a command
to install the "private key+public certificate" of a certificate
for the Android itself. I seem to recall that the Android user
interfaces for these things are a bit confusingly named.

It should be perfectly safe (for the CA) to install the "public
certificate" (with CA=TRUE) of the CA on your phone, PC, posted
on your Google+ profile and any other place you think of, since
this is the whole point (notice how the big names go to extreme
lengths to get theirs included in every browser, OS, Phone etc.
sold). Only the matching "private key" of your mini-CA needs to
be kept in a very secret and locked down place, such as on a
separate CA boot-SD that you only boot from when issuing new
certificates or refreshing your CRL.

> Thanks, best Benjamin!

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

_______________________________________________
openssl-users mailing list
openss...@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

Jeffrey Walton

unread,
Dec 19, 2014, 3:47:26 PM12/19/14
to
On Fri, Dec 19, 2014 at 7:13 AM, Benjamin <benja...@gmx.at> wrote:
> Hello everyone!
> I am quite new to two things: this mailing list and making and working with
> certificates
>
> I want to run a small owncloud on my raspberry pi and tried to make a crt
> which I can also use with my mobile devices. Here is the problem:
> When i make a certificate either with this instruction:
> http://wiki.ubuntuusers.de/CA
> or this one:
> https://www.prshanmu.com/2009/03/generating-ssl-certificates-with-x509v3-extensions.html
>
> i have the problem that the cacert has "basicconstriants CA=TRUE" but when i
> make a cert by request i got a new cert (as far as i knew, that which i
> should use for my nginx webserver) which has CA=FALSE. This is no problem
> normally but my Android phone only accepts Certs with CA=TRUE and actually i
> don´t know how to make such a certificate…Of course, i could use the cacert
> itself but isn´t this insecure and inadequate?

You can't install self signed certificates (CA=FALSE). You can install
client certificates and CA certificates. See
https://support.google.com/nexus/answer/2844832?hl=en.

What you should do is create a CA, sign the web server's certificate
with your CA, and then install the CA on your Android device.

The problem (of the Internet of Things and self-signed certifcates
intersecting with Browsers) was recently brought up on the Web App Sec
mailing list (see
http://lists.w3.org/Archives/Public/public-webappsec/2014Dec/0203.html).
There's nothing available at the moment - the Browsers only support
the CA Zoo security model.

Jeff

Benjamin Draxlbauer

unread,
Dec 20, 2014, 5:19:29 AM12/20/14
to
Okay thanks a lot for the quick replies!
I hope i got that right : it is sufficiently secure and unproblematic to create a CA and use this CA (lets call it root-crt) certificate on my webserver and smartphone and wherever it is needes. In short: you can use the cacert.pem which is produced by ../CA.pl -newca.
And the /private/cakey.pem should be stored in a secret place on a external device which is offline (sd card usb etc. in my cellar).

Is this right?

Thanks for support! 



-- 

Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Jeffrey Walton
unread,
Dec 20, 2014, 3:38:54 PM12/20/14
to 
On Sat, Dec 20, 2014 at 5:08 AM, Benjamin Draxlbauer <benja...@gmx.at> wrote:
> Okay thanks a lot for the quick replies!
> I hope i got that right : it is sufficiently secure and unproblematic to
> create a CA and use this CA (lets call it root-crt) certificate on my
> webserver and smartphone and wherever it is needes. In short: you can use
> the cacert.pem which is produced by ../CA.pl -newca.
> And the /private/cakey.pem should be stored in a secret place on a external
> device which is offline (sd card usb etc. in my cellar).
Using a private PKI (i.e., a  CA you own/manage) is the only solution
I am aware. In the past, you could usually install a self signed in a
cert store and then get a browser to trust it. But that's pretty much
a thing of the past since the CAs and Browsers collude in the
CA/Browser (CA/B) forum; and the CAs want nothing to do with that
because it affects their bottom line (see https://cabforum.org/).
When generating your CSR, be sure to put all the hostnames in the
Subject Alt Name (SAN) and not the Common Name (CN). The IETF and
their RFCs are lenient about hostnames in the CN, but Browser *don't*
follow the IETF. Browsers follow the CA/B Baseline Requirements (and
EV Guidelines), and there are a few extra rules. So the bottom line
is: hostnames in the SAN, and not the CN. Follow it, and you won't
have troubles with browsers.
As for what a hostname is, I usually put anything in there that I use
to address the device. Here, "address the device" means anything I
type in the browser's address bar or ping from the command line. That
include hostname, FQDN and IP addresss (if using static IPs). So if I
had a raspberry pi on my local network (my local network include a
Active Directory with a domain called 'home.pvt'), then the DNS names
listed in the SAN would include:
    * raspberry
    * raspberry.localdomain
    * raspberry.home.pvt
    * 192.168.1.xxx
*If* you be connecting to the raspberry pi from the raspberry pi, then
include localhost in the SAN.
Finally, here's a modified OpenSSL CONF file to help you with
generating the CSR with multiple SANs:
http://stackoverflow.com/a/25274959/608639. You should modify the
names under the section [ alternate_names ].
Jeff
_______________________________________________
Benjamin
unread,
Dec 30, 2014, 6:09:54 PM12/30/14
to 

    
Am 20.12.2014 um 11:08 schrieb Benjamin
      Draxlbauer:

    

    
Okay thanks a lot for the quick replies! 

      I hope i got that right : it is sufficiently secure and
      unproblematic to create a CA and use this CA (lets call it
      root-crt) certificate on my webserver and smartphone and wherever
      it is needes. In short: you can use the cacert.pem which is
      produced by ../CA.pl
      -newca. 

      And the /private/cakey.pem should be stored in a secret place on a
      external device which is offline (sd card usb etc. in my cellar).
      

      

      Is this right?

      

      Thanks for support! 

      

      
).
There's nothing available at the moment - the Browsers only support
the CA Zoo security model.

Jeff


      -- 

      Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
      gesendet.
      

      

      

      
_______________________________________________
openssl-users mailing list
openss...@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users


    

    Finally! 

    I followed these steps:

https://thomas-leister.de/internet/eine-eigene-openssl-ca-erstellen-und-zertifikate-ausstellen/

    In short I did the following:

    
	openssl genrsa -aes256 -out ca-key.pem 2048
	openssl req -x509 -new -nodes -extensions v3_ca -key ca-key.pem -days 1024 -out ca-root.pem -sha512
		
		Country Name (2 letter code) [AU]:xx
		State or Province Name (full name) [Some-State]:xx
		Locality Name (eg, city) []:xx
		Organization Name (eg, company) [Internet Widgits Pty Ltd]:xx
		Organizational Unit Name (eg, section) []:xx
		Common Name (eg, YOUR name) []:mydomainname.no-ip.org
		Email Address []: xxxxx@xxxx.xxx
imported the root-ca:
	sudo cp ca-root.pem /usr/share/ca-certificates/myca-root.crt
	sudo dpkg-reconfigure ca-certificates
	--> import to my android device 
Created a new server cert:
	openssl genrsa -out zertifikat-key.pem 4096
	openssl req -new -key zertifikat-key.pem -out zertifikat.csr -sha512
	openssl x509 -req -in zertifikat.csr -CA ca-root.pem -CAkey ca-key.pem -CAcreateserial -out zertifikat-pub.pem -days 365 -sha512



     then imported the root certificate to my android device and then
    everything worked fine also in my smartphone!

    

    I used as the CN my domain name…is this problematic?

    

    I just want to ask a last time if this is secure enough:

    I stored the root cert. and its private key in a secret place
    (offline usb device) and the public key and the server cert. is in a
    root-folder on the server. Of Course due to androids demand to have
    a CA certificate with basic constraints CA=True the root cert. is
    also on my android device but anyway i didn´t manage to create a
    cert which has this flag (also not with yast2-ca-management because
    it is not allowed to export a ca-authority (CA=true) which i
    understand in a way…) So do i have to consider further security
    actions to protect my server from attacks from outside? 

    

    Thanks for help! Benjamin.
  



0 new messages