Hi Kyle: While your EKU is correct, I'm not sure that your KU values are correct. We've generated successful UCC certs here with the following profile:
[ usr_ucc_ext ] basicConstraints = CA:FALSE keyUsage = critical, keyEncipherment, digitalSignature extendedKeyUsage = serverAuth, clientAuth nsComment = "Do Not trust - CertiPath compliant Server Cert for TEST purposes only" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer subjectAltName = @ucc_san authorityInfoAccess = @aia_points crlDistributionPoints = @crl_dist_points certificatePolicies = ia5org, @carillon_medium_sw_policy [ucc_san] DNS.0 = hostname.carillon.ca DNS.1 = hostname2.carillon.ca DNS.2 = hostname3.carillon.ca DNS.3 = hostname4.carillon.ca DNS.4 = hostname5.carillon.ca DNS.5 = hostname6.carillon.ca [aia_points] caIssuers;URI.0=http://www.host-where-our-certs-are.ca/caops/ca-file.p7b caIssuers;URI.1=ldap://dir.host-where-our-certs-are.ca/DN?... ocsp = URI:http://www.host-where-our-ocsp-is.ca/ocsp [crl_dist_points] URI.0=http:://www.host-where-our-certs-are.ca/caops/crl-file.crl URI.1=ldap://dir.host-where-our-certs-are.ca/DN?... Hope this helps the OP. Have fun. Patrick. On 16/01/10 4:52 PM, Kyle Hamilton wrote: > The next thing is to ensure that its extendedKeyUsage includes 'SSL > Client' and 'SSL Server', and its keyUsage includes dataEncipherment, > keyEncipherment, digitalSignature, and keyAgreement. > > I have not seen any specific extension requirement for SIP. > > Another question is: is your certificate being issued by the trust > anchor itself, or by a sub-CA that's been issued by the trust anchor? > If it's the latter case, you also need to have the intermediate > certificates loaded into your keystore. > > (You can debug this with 'openssl s_client -connect hostname:port > -showcerts'. That'll tell you the certificate that's being sent by > the server, which you can copy and paste into 'openssl x509 -noout > -text', ending the input to that command with either a ^D (on *nix) or > ^Z (on Windows).) > > -Kyle H > > On Fri, Jan 15, 2010 at 4:08 PM, Rausch, Michael > <michael.rau...@us.lawson.com> wrote: >> Thanks. Yes I have made sure they are all in there. >> >> The certificate in question reads out something like: >> >> subject name: servername.subdomain.domain.com >> SAN#1: servername.subdomain.domain.com >> SAN#2: servername.domain.com >> SAN#3: servername >> SAN#4: sip.domain.com >> SAN#5: sip.subdomain.domain.com >> >> Do you need to do anything in particular since it needs to be a MTLS cert vs >> a SSL or TLS cert? >> >> Thanks (and sorry for the double post, not a good first impression huh?) >> >> Thanks all >> >> Mike >> >> ________________________________________ >> From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] On >> Behalf Of Kyle Hamilton [aerow...@gmail.com] >> Sent: Friday, January 15, 2010 5:09 PM >> To: openssl-users >> Subject: Re: Issues generating Certs for Office Communications Server 2007 >> >> The only thing special about OCS certificates is that they must >> contain all the names -- including all possible fully-qualified domain >> names -- that the server can be accessed by in the >> subjectAlternativeName extension. This is the most common reason for >> this error (and the 'help text' in the error description in the event >> log is *absolutely useless* here). >> >> From http://technet.microsoft.com/en-us/library/cc676984.aspx : >> >> 0x80EE0065 - UCC_E_INVALID_CERTIFICATE >> Invalid certificate. When using Transport Layer Security (TLS) as the >> transport (as opposed to TCP), the OCS server is configured to >> authenticate TLS sessions by using a particular certificate that was >> issued to that particular server. Check the certificate configuration >> of the OCS server. Note the FQDN to which the certificate was issued >> (the FQDN of the server or the pool). The server name in the >> NotificationAgentSIPServer registry key should match that of the FQDN >> to which the certificate was issued. >> >> Resolving configuration issues with Microsoft software is a bit >> outside the scope of this mailing list; the only thing that we can do >> is point you to the extension that might be causing you trouble. (If >> you don't see the full list of names that your server is known by in >> subjectAlternativeName, then the configuration file that the other >> group uses for their openssl CA doesn't allow for 'copyextensions = >> copy' or 'copyextensions = all'.) >> >> -Kyle H >> >> On Fri, Jan 15, 2010 at 1:49 PM, Rausch, Michael >> <michael.rau...@us.lawson.com> wrote: >>> I have an Office Communications Server 2007 and an OpenSSL CA (which is >>> actually managed by a different group). >>> >>> >>> >>> Using the OCS Certificate Wizard I have been generating requests, but the >>> Certificates I get back, while importing into the server without issue, are >>> not trusted by the Communicator clients. I get the error “There was a >>> problem verifying the certificate from the server. Please contact your >>> System Administrator.” >>> >>> >>> >>> This error also appears in the Application Log: >>> >>> >>> >>> Event Type: Error >>> >>> Event Source: Communicator >>> >>> Event Category: None >>> >>> Event ID: 5 >>> >>> Date: 1/15/2010 >>> >>> Time: 3:45:30 PM >>> >>> User: N/A >>> >>> Computer: workstation >>> >>> Description: >>> >>> Communicator could not connect securely to server >>> servername.subdomain.domain.com because the certificate presented by the >>> server was not trusted due to validation error 0x80ee0065. The issuing >>> certificate authority (CA) for the server's certificate may not be locally >>> trusted by the client, the certificate may be revoked, or the certificate >>> may have expired. >>> >>> >>> >>> Resolution: >>> >>> A tool like winerror.exe from the Windows Resource Kit or lcserror.exe from >>> the Office Communications Server Resource Kit can be used in order to >>> interpret the error code listed above. If you trust the server certificate, >>> the issuing certificate authority (CA) certificate can be placed in the >>> local trusted root certificate authorities certificate store. If you have >>> logged into the server before without issues the network administrator >>> should carefully examine the certificate if no known configuration changes >>> have been made. >>> >>> >>> >>> For more information, see Help and Support Center at >>> http://go.microsoft.com/fwlink/events.asp. >>> >>> >>> >>> >>> >>> Now I have verified that this CA’s certificate appears in the Trust Root >>> Certification Authorities of the OCS server (and the workstation). >>> >>> >>> >>> So I guess my question would be, is anybody else out there using OpenSSL to >>> generate certificates for OCS 2007? Do I need to generate them in a >>> different way (other than the OCS Cert Wizard) or do they need to be >>> submitted to the OpenSSL CA in a special way? >>> >>> >>> >>> Just looking for some guidance as this has been a roadblock for a while now. >>> >>> >>> >>> Thank you very much for you time, >>> >>> >>> >>> Michael Rausch >>> >>> >> ______________________________________________________________________ >> OpenSSL Project http://www.openssl.org >> User Support Mailing List openssl-users@openssl.org >> Automated List Manager majord...@openssl.org >> ______________________________________________________________________ >> OpenSSL Project http://www.openssl.org >> User Support Mailing List openssl-users@openssl.org >> Automated List Manager majord...@openssl.org >> > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
