Hey everyone,
I have been strictly learning from the SAML Examples.
I am working with a Service Provider to setup SP Initiated SSO for one of their clients.
I’m ready to implement the solution on our test server, but I’m a bit confused about creating my SP specific certificates.
Apologies if these questions are basic -
My SP has a website.
For SP Init SSO, (based on the example), I was going to create a pkv / pfx file to store private keys for signing.
Assume I need to ceate a public key from the pfx and share that with the IDP so they can store it on their side to verify my messages.
This public key is what I will specific when I use ExportMetaData.exe so that I can create an xml with the CERT info requested by my IDP.
Similiary I have to import the public cert provided to me by the IDP so i can verify response back from the IDP.
Questions, am i correct on the above?
The client IDP provided me a metadata.xml that contains their cert, but it looks to me like there are 3 different signing sections in their .xml they provided me with 3 different certs? How do I create a cert from that xml (do I use a import tool to create the cert)?
The client IDP asked me for a “commercially signed certificate”. Is it as simple as running “makecert -r -pe -sky exchange -n “cn=www.myserviceprovider.com” -sv sp.pvk sp.cer”
Then run the exportmetadata.exe against my saml and the sp.cer?
Do I have to run the makecert from the windows server hosting my service?
Thanks in advance, anything you can expand on is much appreciated -
Josh
Hi Josh
Your understanding is correct.
Normally only a single signing certificate is included in the metadata.
You’re welcome to email the metadata to support@componentspace.com and we can take a look.
A commercially signed certificate presumably refers to a certificate issued by a certificate authority (CA).
I’m surprised they’ve placed this restriction.
Using something like makecert to create a self-signed certificate won’t meet their requirement.
What you can do is either purchase a certificate from a CA or use the existing certificate configured for HTTPS support in IIS for your site.
Using the same certificate for HTTPS and SAML support is ok.
Your understanding is correct.
Normally only a single signing certificate is included in the metadata.
You're welcome to email the metadata to support@componentspace.com and we can take a look.
A commercially signed certificate presumably refers to a certificate issued by a certificate authority (CA).
I'm surprised they've placed this restriction.
Using something like makecert to create a self-signed certificate won't meet their requirement.
What you can do is either purchase a certificate from a CA or use the existing certificate configured for HTTPS support in IIS for your site.
Using the same certificate for HTTPS and SAML support is ok.
Perfect, thx again for the great support.
If I use the "existing certificate configured for HTTPS support in IIS for your site."
Do have to request the chain from the certificate provider (assume I probably have access to this on my test server)..
Once I have that CERT in hand, do I configure it the same way as in the ServiceProvider example:
SP Saml.config
LocalCertificateFile="Certificates\sp.pfx"
LocalCertificatePassword="password"/>
Can i create a pfx file from the existing IIS certifcate
(sorry that piece if fuzzy to me)
Thx again,
Josh
You shouldn’t need the certificate chain as this should already be available to the partner provider.
It’s the same as if they browse to your HTTPS endpoint.
The certificate chain should be already exist on their machine.
You have a couple of options for specifying the certificate in your saml.config.
You can export the PFX file from the Windows certificate store using the Microsoft Management Console’s Certificates plug-in.
Alternatively, you can directly reference the certificate in the Windows certificate store by its serial number, for example.
In this case, instead of LocalCertificateFile/LocalCertificatePassword, you would specify LocalCertificateSerialNumber.
For more information, please refer to:
https://www.componentspace.com/Forums/44/X509-Certificate-Management
It's the same as if they browse to your HTTPS endpoint.
The certificate chain should be already exist on their machine.
You have a couple of options for specifying the certificate in your saml.config.
You can export the PFX file from the Windows certificate store using the Microsoft Management Console's Certificates plug-in.
Alternatively, you can directly reference the certificate in the Windows certificate store by its serial number, for example.
In this case, instead of LocalCertificateFile/LocalCertificatePassword, you would specify LocalCertificateSerialNumber.
For more information, please refer to:
https://www.componentspace.com/Forums/44/X509-Certificate-Management
I might be confused.
At a minimum I have to have a private key(my ssl my IIS uses) and provide the IDP with a public key to decipher my SSO request correct?
If I use a LocalCertificate, how do I generate the public key that I should provide them?
I was going to use exportmetadata to provide them my saml xml config, but wasn't sure what certificate to specify?
Your private key is used to sign SAML messages sent to the IdP and your public key is used by the IdP to verify these signatures.
If you’re using the certificate configured in IIS, this means it’s stored in the Windows certificate store.
You can use the Microsoft Management Console’s Certificates plug-in to export the certificate and private key to a PFX file.
You can also export the certificate only to a base-64 encoded CER file.
It’s this CER file that you should supply to the IdP either directly or as part of your SAML metadata.
If you're using the certificate configured in IIS, this means it's stored in the Windows certificate store.
You can use the Microsoft Management Console's Certificates plug-in to export the certificate and private key to a PFX file.
You can also export the certificate only to a base-64 encoded CER file.
It's this CER file that you should supply to the IdP either directly or as part of your SAML metadata.
K - thanks again; much appreciated!
You’re welcome.