RE: Config file subjectAltName and This certificate is not valid (host name mismatch)
Thanks, decided to use one config file since I don't want to sync two different files and from the command line for certs I specify the Subj information and works fine creating a child of the CA with different CN. Got everything I needed for the host I was interesting in testing with. Subject: C=US, ST=North Carolina, O=IBM Corporation, CN=192.168.2.16 X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment X509v3 Extended Key Usage: OCSP Signing Netscape Cert Type: SSL Client, SSL Server -- View this message in context: http://openssl.6102.n7.nabble.com/Config-file-subjectAltName-and-This-certificate-is-not-valid-host-name-mismatch-tp46290p46372.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Config file subjectAltName and This certificate is not valid (host name mismatch)
> From: owner-openssl-us...@openssl.org On Behalf Of redpath > Sent: Thursday, 22 August, 2013 09:36 > I have searched the forums for multiple hostnames and commonName. > I cannot get created Certs that are signed by the CA to have > a commonName supplied in the > config instead of the command line. I also want them to have > subjectAltName fields There are four ways to set Subject DN: from the config file with -batch or prompt=no, on the command line using -subj, or stdin when prompted. SAN, like other extensions, can be set from the config file for the *ca*, or from the config file for the request *if* you use 'ca' (you did) and set copy_extensions (you didn't). > too. I have tried the Policy *match* and basically get errors > for it to > create certs. > I am sure there is some tweak here and enclosed the config file. > Policy doesn't change anything in a cert, it only decides if 'ca' will issue a cert at all. > *I assume this would fix the > * "This certificate is not valid (host name mismatch) > Having the right values in Subject and/or SAN should fix that type of error. Which method you use to get the right values shouldn't matter. If you get only one right, RFCs say the relier *should* take SAN in preference to Subject, but I wouldn't be confident all reliers do. > *Create the CA* > > openssl req -new -x509 -days 3650 -extensions v3_ca > -keyout certprivkey.pem -out myCAcert.pem -config myconfig > -batch -passout pass:CApassword > Note: that puts the CA private key in a location different than where your config file below tells 'ca' to look for it. Did you move or copy it to the right place? > *Make a cert and sign it with the CA for SSL usage.* > > openssl req -new -nodes -out my.csr -days 731 -keyout mykey.pem > -batch -extensions v3_OCSP -config myconfig > > openssl ca -out *mycert.pem *-in my.csr -passin pass:CApassword > -batch -extensions v3_OCSP -cert myCAcert.pem -config myconfig > Nit: req -new without -x509 does not make a cert, it makes a Certificate Signing Request aka CSR. *ca* (if no error) makes the cert *from* the CSR, and signs the cert. A CSR is not a cert, although it has some similarities. More serious: if you use the same config file for the CA cert (req -new -x509) and the "mycert" CSR (req -new), with -batch and without -subj, you'll get a child cert with the same Subject as the CA that issued it. THAT WON'T WORK. THEY MUST HAVE DIFFERENT NAMES. If you use -subj or stdin it's easy to give different input; using solely config files you need two config files. > > *I use the command * > openssl x509 -in *mycert.pem* -text > > *To see the subject field which only shows* > Subject: C=US, ST=North Carolina, O=IBM Corporation > > *and* > > X509v3 extensions: > X509v3 Basic Constraints: > CA:FALSE > X509v3 Key Usage: > Digital Signature, Non Repudiation, Key Encipherment > X509v3 Extended Key Usage: > OCSP Signing > > *My sandbox Config file is below > * As noted there are two ways to set Subject DN from a config file, and you appear to have used an inconsistent hybrid mishmosh which doesn't work. One method is to use req -batch and not -subj, and specify in the DN section (normally and in your case [req_distinguished_name]) at least two lines for each "field" (AVA) e.g. commonName = prompt commonName_default = default or fixed value commonName_min = min optional commonName_max = max optional and specify your values on the "default" lines. The other method is to use prompt=no in the [req] section, and give the fixed values for the attributes directly like commonName = fixed value As for SAN, your config file doesn't request it at all, so it's not surprising you didn't get it. Either: In the config file used by req -new in the extensions section you use (v3_OCSP) add subjectAltName=DNS:name,DNS:name ... and in the config file used by ca in [default_CA] add copy_extensions=copy . Note that this will copy other extensions as well as SAN, so it can be insecure if you process CSRs from anybody who isn't fully trusted. If you yourself do all CSRs presumably you trust yourself. Or: In the config file used by 'ca' in the extensions section you use (v3_OCSP) add the above. This uses the same value for all issued certs, so if you issue certs to multiple systems it's easy to get this wrong. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Config file subjectAltName and This certificate is not valid (host name mismatch)
str [ 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 = North Carolina localityName = RTP#Locality Name (eg, city) 0.organizationName = Organization Name (eg, company) 0.organizationName_default = IBM Corporation # 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) *commonName*= sample.com #Common Name (eg, YOUR name) commonName_max= 64 emailAddress = Email Address emailAddress_max = 40 # 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 ] authorityInfoAccess = OCSP;URI:http://127.0.0.1:8082 # 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:always # This stuff is for subjectAltName and issuerAltname. # Import the email address. # subjectAltName=email:copy # Copy subject details # issuerAltName=issuer:copy #nsCaRevocationUrl= http://www.domain.dom/ca-crl.pem #nsBaseUrl #nsRevocationUrl #nsRenewalUrl #nsCaPolicyUrl #nsSslServerName *[ v3_req ]* # Extensions to add to a certificate request basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment *subjectAltName = DNS:sample.com, DNS:localhost, IP:192.168.2.16 * [ v3_ca ] # Extensions for a typical CA # PKIX recommendation. subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always # 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 [ crl_ext ] # CRL extensions. # Only issuerAltName and authorityKeyIdentifier make any sense in a CRL. # issuerAltName=issuer:copy authorityKeyIdentifier=keyid:always,issuer:always *[ v3_OCSP ] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = OCSPSigning* -- View this message in context: http://openssl.6102.n7.nabble.com/Config-file-subjectAltName-and-This-certificate-is-not-valid-host-name-mismatch-tp46290.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Config file subjectAltName and This certificate is not valid (host name mismatch)
*If I specify the subject fields in the command line instead of the config file* openssl req -new -nodes -out my.csr -days 731 -keyout mykey.pem -batch -extensions v3_OCSP -config myconfig -subj /C=US/ST=North Carolina/L=RTP/O=IBM Corporation/CN=192.168.2.16" *I can get these fields in the Cert. Somehow I want to use the config file for creating certs that will be signed by the CA.* Certificate: Data: Version: 3 (0x2) Serial Number: 4096 (0x1000) Signature Algorithm: sha1WithRSAEncryption *Issuer: C=US, ST=North Carolina, O=IBM Corporation *Validity Not Before: Aug 22 16:57:44 2013 GMT Not After : Aug 12 16:57:44 2015 GMT *Subject: C=US, ST=North Carolina, O=IBM Corporation, CN=192.168.2.16 *Subject Public Key Info: *The issuer is correct our CA and the fake Subject material is correct. Or is this not possible form the config file?* -- View this message in context: http://openssl.6102.n7.nabble.com/Config-file-subjectAltName-and-This-certificate-is-not-valid-host-name-mismatch-tp46290p46299.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
