Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to set up a script to generate SSL certificates for use with IIS. I'm trying to get certificates signed by a an self signed CA cert to work. I'm 99% there but something is sill wrong. This is for use with MSExchange SSL certs. I want to have long life self signed certificates and to have a root cert which I can install on devices like smartphones which will allow me to trust other certs I have signed with it, like SSL certs.

This is what I'm doing:

/// create a private root cert
openssl genrsa -des3 -out work\Private-CA.key 2048 

openssl req -new -x509 -days 3650 
    -key work\Private-CA.key
    -out work\Public-CA.CRT

/// Create an SSL cert request
openssl genrsa -des3 -out work\Certificate-Request.key 2048 

openssl req -new 
    -key work\Certificate-Request.key
    -out work\SigningRequest.csr

/// Sign the request with the root cert
openssl x509 -req -days 3650 -extensions v3_req 
    -in work\SigningRequest.csr
    -CA work\Public-CA.CRT
    -CAkey work\Private-CA.key
    -CAcreateserial 
    -out work\SSL-Cert-signed-by-Public-CA.CRT

The first 4 commands seem to be fine. The final command is generating a certificate which has the attributes I want.

I import the Public-CA.CRT into the machine Store as a trusted root certificate. I then use exchanges import-exchangecertifiate cmdlet to try and import SSL-Cert-signed-by-Public-CA.CRT. This fails with a message saying that the certificate is not trusted.

It would appear it is not being signed. If I import the ssl cert into to machine personal store, it also indicates that it doesn't have a certification route.

Can anyone with a better knowledge of this see what I'm missing?

As an aside: Is there any way, from the command line, of asking openssl if Certificate X has been signed by Certificate Y? This should work but doesn't:

openssl verify  -cafile Public-CA.CRT SSL-Cert-signed-by-Public-CA.CRT
usage: verify [-verbose] [-CApath path] [-CAfile file] [-purpose purpose] [-crl_check] [-engine e] cert1 cert2 ...
recognized usages:
       sslclient       SSL client
       sslserver       SSL server
       nssslserver     Netscape SSL server
       smimesign       S/MIME signing
       smimeencrypt    S/MIME encryption
       crlsign         CRL signing
       any             Any Purpose
       ocsphelper      OCSP helper

adding -purpose doesn't make matters any better.

share|improve this question
add comment

1 Answer

You should be importing the CA's public key, not the private key, into the trusted roots store - the private key should never leave your CA.

Trust the CA's public key, and Exchange should then have no problem importing the newly generated certificate.. though, it sounds like you're only giving it the public key and not the Certificate-Request.key file?

I'd recommend generating the certificate signing request from the Microsoft tools on the Exchange server then signing it on the CA - or if you don't do that, at least package the key and certificate pair in a PKCS12 file to feed to the Exchange cmdlet, as it looks like that's the format it wants to use for any import of a private key:

openssl pkcs12 -export -out work\Exchange-Cert-Package.pfx -in work\SSL-Cert-signed-by-Public-CA.CRT -inkey work\Certificate-Request.key
share|improve this answer
    
oops, that was a typo.. corrected. I should have said that I'm importing the public-CA.crt. I'll give a go an packaging the key. –  Ian Murphy Feb 1 '12 at 11:45
    
Well, it did't work. thinking about it, the pfx only contains the SSL cert and the key used to generate the request for it, so it can't contain anything to link it to the root cert or the root cert itself. I get the impression that I'm creating a self signed cert and not one signed by the CA cert, even though thats what it looks like i'm doing. something is missing in what I'm doing. –  Ian Murphy Feb 1 '12 at 15:25
    
@Ian The certificate is issued and signed by the root certificate, so a system that trusts the root will trust the certificate that it issued (and recognize the signing relationship). What error are you getting when you try to import the .pfx? And can you confirm that the root certificate's public key is in the trusted roots store? –  Shane Madden Feb 1 '12 at 16:21
    
The pfx imports fine but I end up with just the ssl cert and no root cert. If I manually import the ca cert into the trusted root store. It imports just fine. If I import the ssl manually to the personal store then in the properties tab it indicates that the validation route is not correct. If I use the import-exchangecertificate powershell cmdlet it refuses to import it because it doesn't have a valid root certificate. (I don't know what the text is in english as I'm translating it) –  Ian Murphy Feb 1 '12 at 22:48
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.