Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: code signing

...

We strongly recommend that you create personal admin users (not shared ones), to be able to see who has done what in the system.

It has been reported was earlier the case that some privileges (management of peer admins, Allow DCV) cannot could not be assigned by one RAO to another. If that affects your organization email tcs@sunet.se to have it fixed manually. Tell us the usernames involved and what privileges you want to add. We'd like that email to come from an admin that already has "Allow creating/editing of peer admin users" instead of the admin who wants more privileges.

Locked Account

This is no longer the case - if you can create/edit peer admin users, you can delegate your privileges too.

Note: the Automatically approve certificate requests privilege seems to be a bit misnamed after recent changes. Without it, the admin does not get the manual Approve button either. Thus, you need to set this privilege for admins that should be able to request and approve certificates.

Locked Account

You can get locked You can get locked if you fail to login a number of times. You will then get an "Incorrect login details, account is locked, password has expired or your source IP is blocked." message when you try to login, even if you use the correct password. It will be the case even if your password have been changed by another admin who can do that for you. This requires the lock to be reset and that can only be done by an MRAO, so you need to contact tcs@sunet.se.

...

Since spring 2023, both kinds of code signing certificates (OV and EV) needs to have the key generated on and confined to a hardware token (before this, "soft" OV code signing certificates were possible, were you generated the key on a normal computer).

See the Code Signing parts in GEANT FAQ for general information. We will update this section when the first Sunet TCS member has ordered an OV code signing certificate and gone through the process with usFrom the array of options described there, we think most Sunet TCS members would choose:

  • Buying a Yubico FIPS Yubikey yourselves (not from Sectigo) and using it to generate a key (which stays on the device) and a CSR + key attestation (which proves to Sectigo that the key was generated by the device) that is used in the SCM interface to order the certificate at no extra charge. This gives you an OV code signing certificate (which is fine if that is what you need, but if you need EV code signing, it will not suffice) using an ECC key (which is fine if that works for your application, but not if you need RSA).
  • Buying an EV code signing certificate on a hardware token from Sectigo using the URL and discount code provided in the GEANT FAQ above. You will not be using SCM for this (you order from Sectigo's "normal" webstore; TCS just provides the discount code) so the extended validation will be done specifically for this purchase. Sunet TCS members using this option have received certificates based on RSA keys.

Notifications

Under Settings → Email Notifications you can add and edit what notifications the system will send you when certain conditions are met. Use the Add button to have a look at the various Notification Types that are available.

...

Authentication is via login name and password for a RAO or DRAO admin. The customerUri is "sunet".

For semiautomatic API use, for example scripts run by a person on the command line, it is fine to use the normal admin user for that person.

For fully automated API use, we We recommend that your create separate RAO or DRAO admins to use with the API instead of reusing the same admins as for web UI work. To create an API-only admin:

  • Use your RAO to create the new admin as you would create a "normal web UI admin", including setting a temporary password. You will not be able to use the API with this temporary password.
  • Login to the new admin in the SCM and perform the mandatory initial password change for it.
  • Back with your original RAO, edit select the new admin and set the "WS API use only" flag for ituse the Change Type button to change this user to an API user.

More gotchas we have discovered, so you do not have to discover them too:

  • To be allowed to use the You may need to enable API calls for handling certificates, you must edit the appropriate Organization or Department object, and on the SSL Certificate tab, enable the Web API checkbox. You will be required to provide a value for the Secret Key field too. Enter a good random value there and promptly forget it (it is not used for the current REST API but for an older SOAP API)your Organization or Department. Select it in the admin interface, use the Certificate Settings button in the information card at the right, Select SSL Certificates in the dialog, enable "Enable Web / Rest API" and save.
  • Be aware that the "serverType": -1 in their certificate enroll example refers to the "other" Server Software type, so if you have removed that when cleaning up useless Server Software types, that example will not work.

As inspiration for API use, Fredrik Domeij at UmU LADOK has provided bash scripts to request and retrieve certificates. You find them as umu-example-api-bash.tarladok-sectigo-bash-2024-02-09.zip.

 ACME support

There is support for ACME and some of the test members have started to try that. We will update this section as we get feedback.

...

Do we really need all those certificates in the chain?

No. You Your webserver or similar should be fine with only sending the GEANT-branded sub-CA certificate (CN = GEANT OV RSA CA 4 or similar) configured as a chain certificate in your together with the server certificate. That The GEANT sub-CA certificate is signed by a version of CN= USERTrust RSA Certification Authority that is present in modern browser/OS trust stores and similar.(this version is self-signed, and does not rely on CN = AAA Certificate Services).

If you need the good version of CN= USERTrust RSA Certification Authority  to import in some software (for example newer versions of VMware that does not like the CN = AAA Certificate Services root),  you can find it via the link on Sectigo's documentation page Sectigo Chain Hierarchy and Intermediate Roots

Where can we check if our server sends the correct chain?

...