View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000788 | Main CAcert Website | certificate issuing | public | 2009-11-09 17:37 | 2013-01-07 22:01 |
| Reporter | mazzo | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | new | Resolution | open | ||
| Summary | 0000788: Altnames can only be assigned when in CSR | ||||
| Description | At the University of Zurich (Organization assured by CACert) currently we use two domains, the old .unizh.ch and the main domain .uzh.ch. This enforces us to use SubjectAltNames in order to avoid certificate warnings to the end user, e.g. issuing certificates working for idlmail01t01.uzh.ch and idlmail01t01.unizh.ch. This is not an issue for common apache/imap/smpt CSR based on linux systems where openssl is used to generate the CSR. Unfortunatelly we have some appliances like Siemens systems, Cisco routers and more where the CSR must be issued within the appliance without an option to add SubjectAltName fields. In addition, the private key is sometimes not exportable, omitting the option to create the CSR containing the correct SubjectAltNames using openssl. With our own CA, which we would like to replace with CACert, we have been able to create certificates adding the SubjectAltNames while creating the certivicate. We would be happy, if such an option could be added to the Organization Assurance Panel for servers. Without this option, we will not be able to use CACert.org as a full replacement for our server certificates and our hope to help to spread the CACert Root Certificates will suffer. | ||||
| Additional Information | At the Swiss Federal Institute of Technology in Zurich (ETHZ), also Organization Assured CACert Memner, the same feature would be appreciated. | ||||
| Tags | No tags attached. | ||||
| Reviewed by | |||||
| Test Instructions | |||||
| related to | 0001101 | needs work | TimoAHummel | general rewrite of get info from csr routine in includes/general.php |
|
|
Applicability: this is because they are using old or non-compliant equipment. Basically subjectAltName should be used for all these purposes going forward, the older methods are deprecated. But it may be that the suppliers of equipment don't care, so this might be a more widespread problem. Security-wise: Not sure. If we have a valid signed CSR from an org, then the ability to fiddle with the params after it is received is possible. Resources: That looks like a development task. If you could find a developer willing to do it, then it could possibly be entertained. But it doesn't look trivial, it involves intercepting and fiddling the info in a way it wasn't really envisaged to be? Or it might be easy using the API. Looks low priority to me. |
|
|
I talked about this with PG last night. One potential solution is to modify the certificate created according to instructions otherwise found in the CSR. So for example if there were multiple CNs with the appropriate domain names, these could then be simply transferred across to SANs. The question circulates around where the authority comes from. If the authority to add SANs is found in the CSR itself, that is fairly tractable. If the authority has to be found externally, then it gets messier. There is a potential attack here where a CSR from one place could then be modified into a cert and used in some obscure claim. |
|
|
The problem here is that this violates the general security-model of certificate requests. The security-model is that the owner of the key has to authorize the certificate request. To achieve this, the certificate request contains the names the certificate should have, and the certificate request is digitally signed with the private key of the requester. The threat-model here is that someone could get a certificate for someone else's keypair, without the consent/approval of the keypair-owner. The proper solution to this problem is to add proper names in the certificate request, and to fix the software that generated the certificate request, to allow entering of multiple names. Adding additional SAN's that aren't requested by the secret-key owner would be a breach of security. Please give us details about which Siemens and Cisco models/software/versions are affected, so that we can negotiate a solution with those vendors. |
|
|
It seems the security model under which certificate requests are generated differs from the security model of a CA. My interpretation of a CA security model is that certificates of specified types (CPS) are issued to a member who has demonstrated control/ownership over a domain. Issuing certificates with SANs domains not in the CSR isn't a contravention of the CA security model provided the member has control/ownership of the domain. Though it is possible to issue a certificate without the consent/approval of the private key owner the usefulness is rather deminished as the certificate is public and all authentication models prove the possession of the private key. The case desired by the requester seems reasonable. The proper solution is for all software to produce flexible CSRs however accommodating this feature request doesn't seem to violate any explicit community/social expectation and could be incorporated into the CPS with a small non-controversial rewording. |
|
|
Hi all Thank you, Daniel for your statement. It would be really astonishing if it would not be possible, since even VeriSign (and other major CA's) are allowing to add SAN's on certificate creation. I'll add a pdf-document showing the enrollment page we have for MangedPKI at Verisign. Concerning the fact we are using old equipment and software, one of these is Lotus Notes in the last release 8.5.1. We tried to talk to IBM, I think that nor IBM, nor Cisco are willing to change anything. Yes, Ian, we see it as a development task and if the community agrees to make it possible, we will try to develop it or find some funds to develop it. Regards Roberto |
|
2010-01-11 09:53
|
|
|
|
the csr can be created by openssl or whatever software including one servername on create the signed public key you have to select the issuing class1 or class3 cert. if, as shown in the enrollment...pdf now also a list of addtl. servernames can be added, the following procedure can walk thru the list of all servernames, given in the csr + the servernames from the form and can be checked against the list of added domains linked to the users account / org account the last step is the signing process ... so what is the problem here ?!? to allow adding addtl. servernames in the initial "new cert form" here ?!? from mazzo's sample: domains listed and verified: .unizh.ch + .uzh.ch csr includes idlmail01t01.uzh.ch in the form user adds: idlmail01t01.unizh.ch the resulting signed cert includes: idlmail01t01.uzh.ch + idlmail01t01.unizh.ch both domains are verified before and linked to the account. The account the user is now using for starting the server signing request the csr + editing addtl. servernames about the "general security-model of certificate requests" ... I'm adding city, country, and further infos into my cert request and receives a signed cert w/o country, city or country/city overwritten ... so whats up with the so called "general security-model of certificate requests" ? my prepared cert request has been modified in the signing process. I'm the verified user of _my_ account. I'm the verfied authoritive person of the listed domains to my account. So adding server names with a domain name that is verified against my account, the signed csr with my private key (under my control) + the addtl. initiated request with added servernames before signing the server cert is backed up by the linking of the verfied domains to the user account. So if I enter idlmail01t01.local to the list of servernames, the .local is not verified, so this servername cannot be accepted. The check process of the given csr and addtl. servernames has to follow the start signing form (csr cannot be checked before as its available first after paste to the form) The only exception I can think off is, that the signed csr with the private key includes a checksum that will later be verified against the private key. But whats with removal or replacement of country/city here ? why does this works? Ok, given country and city is not verified in the users individual account, so therefor cannot be added to the signed key. But this modifies the infos received by the csr ..... |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-11-09 17:37 | mazzo | New Issue | |
| 2009-11-10 21:54 | iang | Note Added: 0001510 | |
| 2009-11-12 15:26 | iang | Note Added: 0001511 | |
| 2010-01-07 11:58 | Sourcerer | Note Added: 0001549 | |
| 2010-01-09 02:08 | Daniel Black | Note Added: 0001550 | |
| 2010-01-11 09:53 | mazzo | Note Added: 0001551 | |
| 2010-01-11 09:53 | mazzo | File Added: EnrollmentServices.pdf | |
| 2011-07-14 23:26 | Uli60 | Note Added: 0002139 | |
| 2011-07-14 23:30 | Uli60 | Note Edited: 0002139 | |
| 2011-07-14 23:47 | Uli60 | Note Edited: 0002139 | |
| 2013-01-07 22:01 | Werner Dworak | Relationship added | related to 0001101 |
