Yes, I thought the same, good to have it cleared out! Thanks a lot, I like to know how it's running :)
2016-07-20 13:26 GMT+02:00 Juan Hernández <jhern...@redhat.com>: > On 07/20/2016 01:21 PM, Matt . wrote: >> Hi, >> >> Thanks a lot, it's good to know about this. >> >> There is no way to shorten the commonname ? or wil it aways used the >> hostname there, as it's cn I doubt if we can use something else there. >> >> Thanks! >> >> Matt >> > > I think it can't be shortened, as most TLS/SSL clients check that the > host name matches exactly the common name inside the certificate, and > this check would fail if you shorten it. > >> >> >> 2016-07-20 13:07 GMT+02:00 Juan Hernández <jhern...@redhat.com>: >>> On 07/20/2016 12:30 PM, Matt . wrote: >>>> Hi, >>>> >>>> I found out yesterday late I was looking in the certs folder for the >>>> serial, this was the issue all files are there. >>>> >>>> I need to test a shorter fqdn, which is a pity, but I wonder why it >>>> should be too long for a cert create. >>>> >>> >>> Looks like it is a limitation of the X.509 specification: >>> >>> ub-common-name INTEGER ::= 64 >>> ... >>> 520CommonName ::= CHOICE { >>> teletexString TeletexString (SIZE (1..ub-common-name)), >>> printableString PrintableString (SIZE (1..ub-common-name)), >>> universalString UniversalString (SIZE (1..ub-common-name)), >>> utf8String UTF8String (SIZE (1..ub-common-name)), >>> bmpString BMPString (SIZE (1..ub-common-name)) } >>> >>> The source is RFC 5280: >>> >>> http://www.ietf.org/rfc/rfc5280.txt >>> >>> Maybe we should check these limits during the setup. >>> >>>> >>>> >>>> 2016-07-20 10:14 GMT+02:00 Juan Hernández <jhern...@redhat.com>: >>>>> On 07/19/2016 07:59 PM, Matt . wrote: >>>>>> Hi, >>>>>> >>>>>> Thanks for the heads up, I saw this in some thread too and this file >>>>>> was available here with the upcoming number. >>>>>> >>>>>> Which rightsdo the file has? >>>>>> >>>>>> I don't have a ca.pem in that cert folder anymore can that be an issue? >>>>>> >>>>> >>>>> In theory the ca.pem isn't needed to sign certificates, but the fact >>>>> that it isn't in that directory probably means that something has been >>>>> incorrectly manipulated, either manually or by the system itself. These >>>>> are the files/permissions from a working environment: >>>>> >>>>> lrwxrwxrwx. 1 root root 28 Jul 8 11:34 apache-ca.pem -> >>>>> /etc/pki/ovirt-engine/ca.pem >>>>> -rw-r--r--. 1 root root 384 Jul 8 11:34 cacert.conf >>>>> -rw-r--r--. 1 root root 384 Jul 8 11:34 cacert.template >>>>> -rw-r--r--. 1 root root 384 Jul 18 20:46 cacert.template.in >>>>> -rw-r--r--. 1 root root 4587 Jul 8 11:34 ca.pem >>>>> -rw-r--r--. 1 root root 923 Jul 8 11:34 cert.conf >>>>> drwxr-xr-x. 2 ovirt ovirt 4096 Jul 18 20:46 certs >>>>> -rw-r--r--. 1 root root 923 Jul 8 11:34 cert.template >>>>> -rw-r--r--. 1 root root 717 Jul 18 20:46 cert.template.in >>>>> -rw-r--r--. 1 ovirt ovirt 667 Jul 8 11:42 database.txt >>>>> -rw-r--r--. 1 ovirt ovirt 20 Jul 8 11:42 database.txt.attr >>>>> -rw-r--r--. 1 ovirt ovirt 20 Jul 8 11:42 database.txt.attr.old >>>>> -rw-r--r--. 1 ovirt ovirt 599 Jul 8 11:42 database.txt.old >>>>> drwxr-xr-x. 2 root root 4096 Jul 18 20:46 keys >>>>> -rw-r--r--. 1 root root 548 Jul 18 20:46 openssl.conf >>>>> drwxr-x---. 2 ovirt ovirt 19 Jul 18 20:46 private >>>>> drwxr-xr-x. 2 ovirt ovirt 4096 Jul 18 20:46 requests >>>>> -rw-r--r--. 1 ovirt ovirt 5 Jul 8 11:42 serial.txt >>>>> -rw-r--r--. 1 ovirt ovirt 5 Jul 8 11:42 serial.txt.old >>>>> >>>>>> >>>>>> >>>>>> 2016-07-19 19:08 GMT+02:00 Juan Hernández <jhern...@redhat.com>: >>>>>>> On 07/19/2016 06:16 PM, Matt . wrote: >>>>>>>> Can anyone confirm what max. number of subdomains can be used for a >>>>>>>> certificate ? >>>>>>>> >>>>>>>> The length of 65 per subdomain should be default. >>>>>>>> >>>>>>>> 2016-07-19 15:06 GMT+02:00 Matt . <yamakasi....@gmail.com>: >>>>>>>>> It's the fqdn indeed, not it's hostname. >>>>>>>>> >>>>>>>>> Fqdn should be possible I thought as discussed before in the channel >>>>>>>>> (while ago). >>>>>>>>> >>>>>>>>> 2016-07-19 15:04 GMT+02:00 Yaniv Kaul <yk...@redhat.com>: >>>>>>>>>> >>>>>>>>>> On Tue, Jul 19, 2016 at 3:43 PM, Matt . <yamakasi....@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> kvm-01.hosts.services-01.clusters.mycluster-01.dc.ovirt.subdomain.dc-01.dc.my.network >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Is this the name of the host? perhaps it's a bit too long? >>>>>>>>>> Y. >>>>>>> >>>>>>> Not sure if this is relevant, but I had the same problem today, and the >>>>>>> cause was that the /etc/pki/ovirt-engine/serial.txt file was empty, and >>>>>>> openssl refused to open it. I wrote manually a number inside, taking the >>>>>>> value from /etc/pki/ovirt-engine/serial.txt.old (plus one), and then >>>>>>> things started to work. >>>>>>> >>>>>>> -- >>>>>>> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta >>>>>>> 3ºD, 28016 Madrid, Spain >>>>>>> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat >>>>>>> S.L. >>>>> >>>>> >>>>> -- >>>>> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta >>>>> 3ºD, 28016 Madrid, Spain >>>>> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L. >>>> _______________________________________________ >>>> Users mailing list >>>> Users@ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/users >>>> >>> >>> >>> -- >>> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta >>> 3ºD, 28016 Madrid, Spain >>> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L. >> _______________________________________________ >> Users mailing list >> Users@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> > > > -- > Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta > 3ºD, 28016 Madrid, Spain > Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L. _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users